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Coordinator: William Joseph, Virginia Wesleyan College 

Do we know what information technology is costing our institution? How do 
we determine what is needed versus what is desired? Papers in this track 
focus on daily funding and accountability problems, the related management 
of growth, and funding relationships in higher education. 
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ACHIEVING EXCELLENCE IN ACADEMIC COMPUTING 
Paul K. Madonna, Ed. D. , J.D. 
Sacred Heart University 
Fairfield, Connecticut 



Survival in the decade of the nineties will require a campus 
to achieve excellence in one or more areas. The resources of the 
computer hardware vendors are one solution to achieving 
excellence in academic computing. 

The hardware vendor is likely to develop a partnership with 
a campus if the vendor's architecture, technology and software 
become the keystone of the academic computing plan. An RFP 
designed as a performance specification will encourage vendors to 
respond in support of the academic computing plans. 

This approach allows the vendor to bring to the campus the 
critical personnel and financial resources necessary to achieve 
excellence for both the campus and the vendor. The selection 
process therefore turns on the amount of resources the vendor 
will commit to the campus and the extent to which the vendor's 
solutions achieve the level of excellence specified in the 
academic computing plan. 
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INTRODUCTION 

Survival in the decade of the nineties will require a campus 
to achieve excellence in one or more areas. The resources of the 
computer hardware vendors are one solution to achieving 
excellence in academic computing. 

The hardware vendor is likely to develop a partnership with 
a campus if the vendor's architecture , technology and software 
become the keystone of the academic computing plan. An RFP 
designed as a performance specification will encourage vendors to 
respond in support of the academic computing plans. 

This approach allows the vendor to bring to the campus the 
critical personnel and financial resources necessary to achieve 
excellence for both the campus aad the vendor. The selection 
process therefore turns on the amount of resources the vendor 
will commit to the campus and the extent to which the vendor's 
solutions achieve the level of excellence specified in the 
academic computing plan. 

Let us now turn our attention to an analysis of this summary 
of developing a partnership between the hardware vendor and the 
small college and university. 

The Goal 

Within the area of academic computing, it is appropriate and 
logical for the small college and university to establish the 
goal to become the most sophisticated academic computing campus 
in its region for a teaching college or university with 
approximately a 2,000 full time undergraduate enrollment. Such a 
goal has as its objective the attraction of sophisticated 
computer students not only to sustain its enrollment objectives , 
but to establish the base for an enhanced academic computing 
environment. Such a goal also will energize and motivate current 
faculty who yet may not have achieved acceptable levels of 
computer literacy. Additionally, this goal will provide an 
attraction to draw new computer oriented faculty to the campus; 
not only computer science faculty, but faculty from all 
disciplines whose interest and future include the necessity of a 
computing environment. 

The most important aspect in the decision to establish this 
goal is the commitment to enlist the expertise and financial 
support for such a program from the computer hardware vendors. 
This is the hallmark of this entire approach. The small college 
or university does not have the financial, technical or human 
resources to carry off this kind of quantum leap into the world 
of an advanced and sophisticated computing environment. Usually, 
the computing center staff will consist of a director who does 
possess significant expertise, but that person is generally torn 
between various and sundry technical and administrative 
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responsibilities that prohibit the devotion of his or her 
expertise to designing and implementing a sophisticated computing 
environment. The remainder of the center staff, usually three to 
five more people, are entry level professionals without the 
ability to either assume management of the center during a design 
and implementation phase or the ability to assist significantly 
in a design and implementation program. 

The Plan of Action 

When all is said and done, there still remains one small 
item to be accomplished: how to get from here to there I How to 
bring a campus with a mediocre or modest academic computing 
environment to the level where it honestly can be positioned as 
having the most sophisticated academic computing c wironment in 
the region for a small teaching college or university. 

The plan of action that the college or university must 
complete before it makes any contact with hardware vendors is the 
development of a five year strategic plan, a five year plan for 
academic computing and a specific design for academic computing 
on campus. 

First, the college or university must develop a strategic 
plan to demonstrate that it has its goals and mission clearly 
stated; and that these goals and mission show that this is a 
campus looking forward in an aggressive mode that places an 
emphasis on excellence in carrying out its mission and achieving 
its goals. The most important part of this five year strategic 
plan is its financial model. Without a financial model that 
projects enrollments, tuitions and expenditures, the five year 
strategic plan becomes an academic exercise in rhetoric and 
euphemisms. Even more importantly, academic computing must be 
clearly displayed in this financial model so that the hardware 
vendor is assured of the viability of the campus as a potential 
customer. 

Second, the overall University five year strategic plan must 
devote a reasonable section to academic computing. However this 
will not substitute for an academic computing plan that is 
separately written and covers a period of not less than five 
years. Throughout the academic computing plan there must be a 
constant emphasis that this plan is a complete reordering of 
academic computing on the campus, with the design objective to be 
the establishment and acquisition of leading edge technology in 
all areas of academic computing. 

Third, the specific design for academic computing that will 
serve as the link between the academic computing plan and vhe 
request for proposals should focus around the development by one 

-2- 



6 



130 



vendor of a central facility, a totally networked campus and 
departmental computing. The central facility is not a 
traditional computer center, but is a hub in a distributed system 
to handle high volume in complex computing as well as being a 
location for specialized hardware and software. The network will 
bring together every single space on campus into a design of 
universal connectivity in an open architecture format; and most 
significantly, the network will provide unlimited external access 
through the national and international computing network systems. 
While departmental computing plans may anticipate a variety of 
vendors, there must be the ability to access files throughout the 
network with restrictions to such files based only on policy and 
security reasons. 

This design concept is a critical element in attracting the 
computer vendor to the campus and in developing a contract with 
that vendor. It is critical to interact with the vendor in a 
focused and highly specific manner in order to avoid vendor and 
university exchanges and agreements that do not include specific 
hardware, software and other support services associated with 
definite dollar amounts for each item. Therefore, we can 
summarize this first major phase of a university's attempt to 
achieve excellence in academic computing by stating that this 
goal means the establishment of a sophisticated computing 
environment in three components: a central facility, a universal 
network, and peripheral equipment, all operating in an open 
environment of connectivity and communication. 

Campus Resources 

As we move to detail of the specific approaches to 
attracting a hardware vendor to a partnership with the 
university, our analysis will no longer be academic or technical. 
From now on, our discussions will center on the financial. At a 
later point, we will address the interaction of vendor selection 
and hardware and software evaluation. 

The campus has two basic resources to bring to the table 
upon which the partnership will be written: the computing 
expense budget and the computing personnel budget. The computing 
expense budget are those costs associated with hardware and 
software, such as, maintenance, licenses, and financing costs. 
These dollar amounts should be known and used as a basis for 
determining how much money the university can spend towards the 
accomplishment of its goal. The financial model in the strategic 
plan will have addressed the fact that these dollars will 
increase from the thirteenth month after installation of new 
systems until the end of the planning projection. The first 
twelve months of installation are generally under a warranty 
program that negates the need for any maintenance costs; 



3- 



7 



ERIC 



therefore such costs may be allocated to the acquisition of 
hardware and software. 

The computing personnel budget, unlike the expense budget, 
must increase at the beginning of the installation of new 
hardware and software technologies. It would be an unusual 
situation indeed to find a smell university computer center 
adequately staffed to provide the significant academic user 
support services that will be required to utilize the state of 
the art hardware and software that is arriving on campus. Simply 
stated, if this is not a component of the academic computing 
financial model, it is prudent not to proceed further. In order 
to quantify this factor and place it in proper fiscal 
perspective, the increase in personnel means one professional 
staff person devoted to academic user support services for the 
first two years of installation and one more similar person added 
to the staff at the beginning of the third year. Presuming one 
such professional already exists on most university campuses, 
this staffing presumes that the director will have three 
professionals to support the hardware and software needs of the 
academic users, including student users. 

Vendor Resources 

The purpose of a partnership wi-th a hardware vendor is to 
augment the resources of the campus so that the two together - 
the vendor and the campus - may move the campus forward to 
achieve excellence in academic computing. So at the outset, the 
first resource in importance that the vendor brings to the campus 
is the simple fact that the vendor becomes a partner with the 
campus. By attracting the vendor to the campus, the campus is 
able to make a statement that we are in partnership with this 
major national computing vendor - and that is something special 
that sets this campus apart from others. 

Secondly, however, to establish this necessary partnership, 
the campus must be flexible in the specific hardware and software 
technologies that it is seeking so that compatibility of 
university academic computing goals will not be in conflict with 
what major computer vendors are able to provide. A partnership 
is a mutual relationship where each partner contributes to the 
other and works with the other towards a mutual goal; if the 
campus is rigid and predetermined, they cannot achieve a 
partnership that will produce the maximum for the campus. 

Third, a critical, and perhaps the least expensive, aspect 
of this partnership is the assurance by the vendor that the 
campus will have access to its engineers and always be considered 
as a beta site when it is appropriate and logical. If after all 
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of the efforts of a strategic plan, an academic computing plan, 
vendor selection and hardware and software installation, there is 
no commitment by either the campus or the vendor to continue to 
look to the horizon and upgrade and maintain the position of 
advanced technology, then the campus will quickly sink back down 
to the level of a mundane and pedestrian academic computing 
environment . 

Fourth, the campus must insure that the vendor brings to the 
partnership the very latest leading edge hardware and software 
available; not what the vendor believes the campus is currently 
ready to accept. This whole process we have been reviewing can 
be perceived as a change agent. And simply to supply i;he campus 
with more of the same will result in just that - more of the same 
mundane and pedestrian computing. Not only must the vendor bring 
to the partnership the current state of the art, but plans must 
be laid for easy access to future upgrades. 

Fifth, the major computer vendors have the very significant 
resource of being able to provide a variety of financing options 
for the acquisition of hardware and software. While not commonly 
referred to as financing options, the various lease plans should 
be thought of in that perspective so that we may feel comfortable 
in working with the selected vendor and adjusting the costs of 
acquisition and continued maintenance into a payment program that 
will meet the campus's particular budget requirements. One 
should think of the acquisition of hardware and software not as a 
purchase, but as a budgeted expense that can be projected into 
the future. This is not a static or simplistic calculation, such 
as a mortgage amortization schedule, but rather a complex 
negotiation that factors in such variables as delivery schedule, 
acceptance dates, financing charges and whether or not the 
institution may qualify for tax exempt financing. It is at this 
point that the vendor can make the program work or not. 

Finally, a major national computing vendor brings to a 
partnership the enormous publicity that such an organization can 
generate. Whether it is publicity simply wit kin its own client 
base, or in the rare few instances where the publicity is 
national, this is the kind of recognition that enhances 
recruitment of students and faculty as well as energizes the 
current campus community. Free surplus equipment from the local 
insurance company, bank or anyone else making such contributions 
not only does not satisfy the requirement for state of the art 
technology, but brings with it absolutely no prestige or 
publicity. Only the major vendors can bring this to a 
partnership. And for the small university, it requires the 
partnership aspect to obtain this vendor commitment; a simple 
sale of a few P.C.'s or a workstation on an irregular basis will 
not generate a partnership. 
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The Request for Proposals 

Now that we know what we want to do and what we want to 
accomplish and the resources that we have to do it, all we have 
to do is do itl Easier said than done. The vehicle to 
accomplish the campus objective is the request for proposals. 
Normally, these requests are a statement to the vendor of what is 
desired and the response from the vendor is how much it will 
cost. 

In developing a partnership to achieve excellence, we 
instead should make the request for proposals an open invitation 
to all vendors to respond to our goals and expectations as we 
have defined them. Put another way, the small university should 
write a performance specification instead of attempting to 
specify in detail hardware that it wishes. 

Yes, the request for proposals has to include all of the 
administrative and legal boiler plate that is common and 
available. But once that is over and done with and duly entered 
into the bound version, the most important aspect of the request 
is a full presentation of the academic goals and a clear 
invitation to the vendor to design solutions towards that 
academic goal. To repeat what w£6 stated earlier, the academic 
goal states that the university wishes to become the most 
sophisticated academic computing environment in the region for a 
teaching university under 2500 students. It anticipates 
accomplishing this objective by developing a central computing 
facility, a totally networked campus and providing to faculty 
and students appropriate and state of the art peripheral 
equipment such as P.C.'s, workstations, terminals and printers. 
While this does become expanded lJ!S In a full request for proposals, 
that theme is repeated over and over again to the vendor, always 
concluding with the question: what is your design solution for 
our campus. Emphasis must be made that the campus anticipates a 
design solution that presumes a full partnership" with the vendor. 

A critical aspect of the request for proposals is the 
evaluation process that will be utilized by the campus. The 
vendor should know ahead of time that it will be an open process 
in which the two main evaluative criteria will be vendor 
technological creativity and vendor financial creativity. This 
is an evaluation process that places weight on the whole solution 
as opposed to individual segments. 

Besides total cost and financing options, warranty and 
maintenance are clearly major financial issues. Therefore, the 
request for proposals should specifically request that the 
vendors address options to reduce these financial burdens; 
invite extended warranties and reduced maintenance cost programs. 
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When all is said and done, we come to the critical question 
of how do you choose one vendor over another* First, the choice 
should be a ranking based on technology and design solutions to 
the performance specifications* The process for doing that is 
not the intent of this presentation* 

Rather, we are concerned with the second focus of 
competition: the total cost of the whole project. The project 
is the central facility, the network and peripheral equipment. 
Add it all up and there is a total cost. To that cost must be 
added maintenance. Subtracted from that cost is the grant 
support that comes from the partnership. When all is said and 
done, a partnership means, among other chings, that the vendor 
will provide greater than normal discounts or free hardware and 
software. Let me hasten to ada that the partnership will provide 
many other options that we have described above; but at this 
stage * ^ must be price sensitive. We have ranked the vendors by 
their technological solution and have determined which would 
provide acceptable solutions to the campus goal of achieving 
excellence. Now to state it again, we are at the price sensitive 
stage whereby we will enter into a partnership with the vendor 
who provides the hardware and software for our needs at the 
lowest price. 

The critical element in a negotiation that will take place 
at this stage between the two or three vendors ranked highest 
based on technology is that the campus negotiators be open and 
honest with the vendors* The vendors must understand that the 
campus has reached a decision where vendor A, B and C would all 
be acceptable. Therefore, the only issue remaining for 
discussion is the bottom line. The bottom line is more important 
than however the vendors wish to price individual items. An 
extra year of warranty is a deliverable for which there is no 
charge and reduces the bottom line. A positive response from the 
vendor to provide hardware and software for specific programs 
means that a specific amount of peripheral equipment is delivered 
free or at a greater than normal discount. 

After a round robin process of dialogue with each vendor to 
determine what their actual lowest price will be is complete, 
then the choice is made for the lowest price. If the total 
prices are all very close, perhaps within $20,000 to $30,000, 
than the choice should revert back to technological factors that 
differentiate one vendor from another. 

The Balance and the Choice 

What we have tried to accomplish is to place the small 
college or university in the same bargaining position as major 
research universities. The hardware vendor does not sell the 
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product to the entire research university all at once. Rather, 
each program or department in the university operates almost as 
an individual customer, able perhaps to spend a half a million 
dollars a year with the support of university and sponsored 
research funds. With this approach for the small college and 
university, we have said to the hardware vendor that we will buy 
from you the entire computing solution that you have designed so 
that we may achieve our goals of academic excellence. We have 
said to the computing vendor that here is our academic computing 
goal and our basic performance specification - how would your 
company fulfill this performance specification? In this way, we 
become a la\ge customer in much the same way as a department or 
division iii a major research university - we too will spend in 
excess of a half million dollars in this year. 

Case Study: Sacred Heart University 

Sacred Heart University is a small independent teaching 
university located in Fairfield, Connecticut. It has 
approximately 1400 full time undergraduate students, 1800 part 
time undergraduate students and 1100 part time graduate students. 

Sacred Heart University has taken an aggressive posture that 
it will achieve excellence within its mission to serve the 
students of Connecticut and the surrounding northeast region. 
The University believes that for each student it accepts, it will 
attempt to provide an excellent education, whether in basic 
studies, the humanities, business or science. In short, the goal 
of the University is to achieve excellence as a teaching 
university. 

Sacred Heart University has a five year strategic plan that 
states its mission and goals. It is a public document and has 
become the core of the University's decision-making process;. 
When decisions are made, the University asks how does this relate 
to the strategic plan. 

In the Spring of 1989, the University formed an academic 
computing committee to write a five year plan that was completed 
at the end of 1989. That plan was considered as a subset of the 
University five year strategic plan. Thus, they are intertwined 
and support one another. Most importantly, the financial 
modeling in the strategic plan included funding of academic 
computing over and above inflationary increases. 

To bring this academic computing plan to life, the 
University issued a request for proposals that followed the 
precepts described previously. The University received responses 
from seven nationally known computer vendors who provided total 
solutions to its performance specifications. 
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The Academic Computing Committee evaluated those seven 
proposals and recommended further review of three of them* 
Following that further review, two were selected by the Academic 
Computing Committee and the University Administration as being 
equally acceptable as partners with the University to achieve our 
goal3 of 3xcellence. 

Negotiations are underway with these two vendors, with the 
final decision resting entirely upon price. 

No matter which of these two national vendors the University 
selects, we will have made the correct choice of a partner. 
Sacred Heart University brings to the partnership its aggressive 
posture in seeking excellence in academic computing. The 
selected vendor will bring to the partnership all of its 
hardware, software and engineering resources as well as a 
commitment that the University will be offered the opportunities 
to be a beta site for the development of appropriate new hardware 
and software. 

The process works and Sacred Heart University will move from 
having a pedestrian mundane computing environment to having one 
of the most advanced academic computing environments in the 
northeast United States. 
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A DISTRIBUTED MICROCOMPUTER BASED MODEL 
THAT INTEGRATES THE PLANNING/BUDGETING 
PROCESS FOR AN ENTIRE UNIVERSITY- 
A CASE STUDY 



Marshall E. Drummond 
Douglas Vinzant 
Wayne Praeder 

Eastern Washington University 
Cheney, Washington 



Attempting to integrate the various planning and budgeting processes 
that normally are found on a university campus is a challenging and 
often, very difficult undertaking. At Eastern Washington University, 
strong leadership on the part of the university's president and provost 
and a micro-computer based model have enabled the organization to 
take a giant step forward toward realizing that goal. The computer 
model placed a fairly sophisticated analytic tool in the hands of the 
departmental planners with which alternative strategies could be 
evaluated over a multi-year time frame. This study explains how the 
computer model fit into the overall planning process of the university 
and evaluates the effectiveness of its use. 
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A DISTRIBUTED MICROCOMPUTER BASED MODEL THAT INTE- 
GRATES THE PLANNING/BUDGETING PROCESS FOR AN ENTIRE 

UNIVERSITY— A CASE STUDY 

"The "new" strategic plan, and planning process, must necessarily be "bottom-up/' 
Assessing the ability (and necessary skills) to execute-to be responsive, flexible, attentive 
to customers-starts on the front line. Obviously, as the process moves forward, it will 
involve debate among senior officers, and compromise. But it should never lose touch with 
or sight of the front line, where execution takes place/' 

Tom Peters 
Thriving on Chaos 

INTRODUCTION 

Following a period of expansion in the '70s and early '80s, Eastern Washington University 
began to feel the pinch of that expansion in the form of an overextended budget. There was 
also a change in presidents at the university. External to the university, but at about the 
same time, the State of Washington through the Higher Education Coordinating Board had 
developed a master plan for public higher education, including the identification of long 
range program parameters for each of the state's public universities. The result of these 
internal and external conditions was a great deal of uncertainty within the university about 
what directions the university would pursue and how it would go about doing so. 

To address this problem, the university under the leadership of the president and provost 
set out to clarify what the university would try to achieve over the next several years and 
to gain consensus within the university on how that should be done. The vehicle they chose 
to accomplish these ends was, not surprisingly, implementation of a strategic planning 
process. And so, in the last several years, the administration in consultation with faculty, 
staff, and students has rewritten its mission statement, clarified programmatic responsibili- 
ties, and consolidated previous gains in an effort to better prepare the university for the 
future. 

This paper provides an overview of the process utilized by Eastern Washington University 
to bring about the redirection of the university. Particular attention is devoted to the 
microcomputer based model which has been the key to successful integration of the 
university's planning and budgeting processes. 

UNIVERSITY PLANNING/BUDGETING PROCESS 

University process 

As noted earlier, the State of Washington through the Higher Education Coordinating 
Board had provided some very broad directional statements for Eastern in the master plan 
for higher education. In concert with the directions established in the master plan, the 
university began to develop a statement of widely accepted and supported goals for the 
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university in the fall of 1988. As a result of those efforts, three goal categories were 
identified: 

1. learning; 

2. student development; and 

3. university management. 

In addition, goal statements and critical success factors were identified under each of these 
categories. These statements provided overall direction for the university and laid the 
foundation for initiating a comprehensive planning process in the 1989-90 academic year. 

Sta ges of development 

To address the need for faculty and staff participation in developing and implementing the 
university's plans, a process was designed which can be characterized as a "bottom-up" 
approach. In other words, to achieve the desired broad-based participation and consensus, 
the process was designed to occur in four developmental stages: 

1. department plans; 

2. college or division plans; 

3. vice presidents' plans; and 

4. university-wide plans. 

In this four-stage, "bottom-up" process, plans are rolled up to the next higher level, where 
they become the basis for developing the succeeding level's plans. The process continues 
until the final university plans are completed and adopted by the university's Board of 
Trustees. This approach enables all constituent groups in the university community to 
express and promote their values and priorities in shaping the university's agenda for the 
planning period. 

Expected Outcomes 

The planning process was initiated with the expectation that a number of products wouid 
result from its implementation. The most tangible outcomes of the process are program 
plans and budgets at department, college or division level, vice presidents, and university 
level. At each of the four developmental stages, plans have been produced which include: 
vision narrative - a description of the program as it will exist at the dose of the six year 
planning period; strategies - the key actions or decision points which must be implemented 
each biennium of the plan period to bring about the changes called for in the vision 
narrative; and operational plans - the resource requirements (operating and capital) 
necessary to implement the strategies. 

The operational plans are developed using the micro-based resource requirements model 
and essentially represent the annual operating and capital budgets required to implement 
the program directions identified in the vision narrative and strategies. This is a critical 
aspect of the university's process which differentiates it from most attempts to link 
planning and budgeting. Rather than going through separate exercises for planning and 
budgeting, we have integrated the two; the tool we have utilized to accomplish this 
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integration is the resource requirements model. 

Typically, imiversities have planning processes which are separate and distinct from the 
budget process. It is this separation which encourages decision-makers to be unwilling to 
make hard choices in the planning process in the same manner that they must be made in 
the resource allocation process. Often, the result of this phenomenon is that plans are 
adopted requiring resources far beyond those available to the university. As a result, when 
the budget process begins, the plans are set aside and decisions are made with little or no 
reference to the plans. 

With the demographics of the later part of this decade soon to be upon us, effective planning 
for replacement of faculty members is critical to the viability of the university. The plans 
under development will enable the university to evaluate where anticipated vacancies will 
occur and initiate appropriate recruiting measures to replace retiring faculty. 

The information derived from the process for information technology and facilities will 
also be used to develop a campus technology plan and a campus facilities master plan. 
These efforts are commonly not integrated into a university's planning process; they are 
more likely to be operating separately, leading to decisions which are not in agreement with 
one another in the choice of program direction, technology requirements and facilities 
needs. By including these key elements in the overall planning process, the university 
hopes to achieve an integration of program planning, information technology planning, 
facilities planning, and budget development. 

In addition to the tangible outcomes which the plans and budgets represent, there have 
been a number of very significant intangible outcomes of the process. Some examples 
include: development of a broad base of understanding and support for the directions 
established for the university; and the incorporation of longer term programmatic goals in 
short term operational decision-making processes throughout the university. In an organi- 
zation as diverse a^ x a university these outcomes are significant, yet difficult to achieve. 

The next section describes the steps the departments went through in developing their 
plans and recommendations. 

Departmental planning/budgeting process 

Each department followed the same series of eleven steps in developing their plans; they 
are displayed in the diagram bek>w. 
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EASTERN WASHINGTON UNIVERSITY 
PLANNING PROCESS 

I. DEPARTMENTAL PLANS 



JANUARY 29, 1990 



1 OMR 
VISION 



MARCH 12-15, 1990 



APRIL 17-18, 1990 



APRIL 20, 1990 



I 



2 RERNE 
VISION 



I 



3 DEVELOP 
STRATEGIES 



4 MARCH PLANNING 
WORKSHOPS 



I 



5 OERNE AND PRIORITIZE 
PROGRAMS/FUNCTIONS 



iklLOCATE RESOURCE^ 



BY PROGRAM 



II R0LL4JPT0 
DEPT. LEVEL 



COMPARE TO 
BASELINE 



{9 REVISE IF IN EXCESS OF BASELINE) 



10 APRIL PLANNING 
WORKSHOPS 



I 



11 SUBMIT TO KAHpm COMPLETION OF 
division DBECTORB DEPARTMENTAL PLANS 



STEP ONE was development of the components of the vision narrative. STEP TWO was 
to ensure that the vision directly addressed accomplishment of university goals and did 
so within the parameters established by the university planning process assumption. STEP 
THREE required development of strategies for each biennium (two year period) of the six 
year planning period . STEP FOUR was a series of workshops which provided departments 
with the opportunity to discuss interdepartmental and intradepartmental program link- 
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ages. In addition, deans and division directors reviewed the progress of departmental 
plans and provided feedback on the directions being taken by departments. The greater the 
involvement early on in the planning process of senior managers, the less need there was 
of substantive changes in the plans at subsequent stages of development. These workshops 
were also used to introduce the resource requirements model to the planning process 
participants. 

STEPS FIVE through EIGHT required use of the resourcerequirements model software (the 
model is discussed in greater detail in a later section of the paper). These steps include 
identification and prioritization of departmental programs or services as well as the 
resources necessary to support them. At this point, departments had completed their plans 
requiring resources equal to 1XX% of their baseline budgets. 

STEP NINE applied only to the 100% of baseline scenario. This meant going back to STEP 
THREE and reworking strategies and operational plans until they did not exceed the 
baseline funding amounts provided in the model. STEP TEN was a second series of 
workshops in which departments presented their final plans including: vision narrative, 
strategies (two scenarios - 100% and 1XX% of baseline), and operational plans (two 
scenarios - 100% and 1XX% of baseline). As a result of information received in the 
workshops, departments made any final modifications to their plans. STEP ELEVEN was 
the final step in the first stage of the university's planning development process. Depart- 
ments submitted a complete set of their plans, including vision narrative, strategies, and 
operational plans (hardcopy and diskette) to their dean or division director. 

The subsequent stages of development followed essentially the same series of steps as the 
ones outlined above, but were based on roll-ups of the departmental plans. When changes 
were made in the later stages of development, managers were required to go back and 
revise the departmental plans accordingly. This process required extensive dialogue 
between the different levels of management in the university. 

Integration with information technology plan 

The planning process for the use of information technology is often a stand alone process 
at many universities. The drawback of such a process is that the requirements or needs 
identification process usually is conducted by an information technology planning study 
team. In an integrated university planning process, the information on the individual 
functions requirements and needs are submitted up through the organization itself. This 
makes the aggregation of needs as well as the priority setting process much simpler. The 
following diagram shows how the IT planning process at Eastern Washington University 
has been integrated into the overall university planning process. 
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Information Technology Master Plan Paradigm 
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Projects to 
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and implement 
Strategies 



ADP Configuration 
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implementation of 
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Projects 
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ITMP 
Document 



Various IT I 
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Strategic Plan 



Portfolio of 
Projects 



Tactical Plan 



Even though it must lag behind the overall university planning process the IT plan results 
will be considered equally along with all the other organization units plans. Recommended 
priorities for technology projects for the entire university will be done by the university IT 
governance groups. The final information technology plan will follow a format and process 
similar to that commonly required within the State of Washington. 
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INFORMATION TECHNOLOGY PLAN 

One of the goals of the information technology planning process is to integrate information technology planning with agency business planning. 
The following is the suggested format for technology plans from the State of Washington. 



Agency Business Planning 

• Define the agency's business (agency mission) 

• Define the business strategy (what strategies 
will be employed to improve effectiveness?) 

• Develop and document agency goals and 
objectives 

• Define agency business activities 

• Define agency information requirements to 
support business activities 

• Define information technology's role in 
supporting the business strategy 

• Identify inter-agency cooperative initi .-lives 
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State Information Technology Principles 

Each agency is responsible for managing the information 
technology resources necessary to carry out the mission of the 
agency. Agency plans will be consistent with the overall state 
strategic direction. 

All data collected, generated, and used by state agencies is 
managed as a resource of the state. Agencies share data across 
organizational lines to meet program needs, within appropriate 
levels of security and privacy. 

The information technology architecture is capable of supporting 
the necessary interconnections among state agencies and between 
government and other entities. 

The state government workforce has appropriate tools and 
information to extend its capabilities for effective and efficient 
delivery of services. 



Agency Strategic Plan for Information Technology 

Management 

Strategy for executive involvement 

Strategy for selection and management of projects 

Data Resources 

Strategy for information management and information sharing 

Technology Infrastructure 

Description of the planned infrastructure (including networking and computing environment) 

Human Resources 

Strategy for providing the workforce with information resources and tools 
Strategy for organizing the information services function 



i 



Agency Information Technology Tactical Plan 
(Resource Allocation Level) 




Agency Goals and Objectives for Information Technology 


Major Project Plans 


Planned Changes to the Data Infrastructure 


Security and Disaster Recovery Plans 


Application System Plan 


Facility Plans 


Planned Changes to the Technology Infrastructure 


Expenditure Plans 


Human Resource Plans 
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DESCRIPTION OF THE DISTRIBUTED MODEL 

Excel model 



Components of the Resource Requirement Model 



PROGRAM DEFINITION 

This worksheet is used to identify all programs offered by the department and to identify 
requirements for these programs. 



PROGRAM PERSONNEL STAFFING MATRIX 

This worksheet is used to identify each person's role in all programs identified in the Progran 
Definition worksheet. One Staffing Matrix is completed for each fiscal year. 



FINAL RESOURCE ALLOCATION PROJECTIONS 

This is a summary worksheet that identifies FTES/FTEF formula driven allocations and 
allocations entered on one or more of the exceptional resource allocation worksheets. 



EXCEPTION RESOURCE ALLOCATIONS 

The exception resource allocation worksheets are used to itemize exceptional resources required 
for department programs. Any or all of the three exception resource allocation worksheets can be 
used by a department. Entries from these worksheets are automatically totaled in the Final Resource 
Allocation Projections worksheet the next time the Final Allocation worksheet is recalculated. 
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OTHER 
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The resource requirements model is composed of six different Microsof t Excel worksheets 
which are used by department managers to allocate resources for the department over the 
six years of the planning period. Although department budgeting and planning could be 
completed using paper worksheets, the resource requirements model is far superior due to 
its speed and accuracy; this is particularly true when managers wish to evaluate resource 
requirements of alternative strategies. The model is composed of six worksheets. These 
allow the department manager to identify annual budgetary requirements in each of the 
following areas : 

1. Department programs (or functions) and their components; 

2. Personnel requirements; 

3. Operations exceptions (non-personnel requirements); 

4. Facility requirements; 

5. Technology and information resources requirements; and 

6. Resource allocation projections (summation of inputs from #l-#5). 

Two different resource requirement scenarios were developed by each department. The 
first, the 100% of baseline scenario, assuming that the same amount of funding they had the 
previous fiscal period would be available and the second scenario, the 1XX% of baseline 
scenario, assuming that funding above the baseline would be available. 

EV ALUATION OF THE FIRST ITERATION OF THE SYSTEM AND PROCESS 

Process 

Without question, the single most important factor to the successful implementation of this 
process was the support of the university's president and provost and their commitment 
to involving departmental managers in the entire development process from the outset. 
This point cannot be emphasized too strongly for universities considering implementation 
of a similar process. 

It should also be recognized that this type of heavily participatory process requires a 
substantial amount of time and will not be successful unless it truly becomes a management 
priority which supersedes (at times) all of the other activities for which managers are 
accountable. The process is not one which can be started and finished in three months; it 
v/ill require anywhere from twelve to eighteen months to complete the first cycle of the 
process due to the training and learning curves associated with the process. 

Model 

Probably the most obvious and important lesson in utilizing a computer model to assist in 
a planning /budgeting process is the need for matching user skills with the model's degree 
of sophistication. The balance that must be achieved is securing the amount and type of 
information necessary for decision-makers to make informed programmatic choices on the 
one hand while keeping the model from becoming so elaborate and complex that managers 
are unable to use it. 
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While the model enabled mangers at all levels of the organization far more accurate and 
sophisticated analysis of data, it required some basic understanding of micro-computer 
usage which was lacking in some cases. The result was that those managers who were 
unfamiliar with micro-computers had to develop their information by hand on hard copy 
and then have it keyed into the model. Managers who adopted this approach often did not 
use the model to do the "if.., then./' type of analysis available to them through the model. 

One of the difficulties of using this particular computer based model had to do with the 
limitations associated with using a two dimensional spreadsheet package rather than a 
more sophisticated package such as relational database software. The problem once again, 
however, was the development time frame — which was very short — and user skill level. 
While the spreadsheet allowed adequate analysis at the departmental level, as departmen- 
tal plans were rolled up to division, vice presidential, and university levels, it could only 
be used in a limited manner. To address this problem, the university will be using PC 
Express to evaluate the data at the aggregated levels later in the process. 

Where we go from here 

In the spring of 199 1, the president will present the final plans to the university's Board of 
Trustees for adoption. The budgets developed in conjunction with the plans will be 
adopted by the Board shortly thereafter. These two actions will signify completion of the 
first cycle of the university's planning process. From that point on, every year prior to the 
start of a new biennium, the plans and budgets will be revisited and adjusted, ensuring that 
programmatic and budgetary decisions are consistent with the goals the university has 
chosen to pursue. 

CONCLUSION 

Attempting to integrate the various planning and budgeting processes that normally are 
found on a university campus is a challenging and often, very difficult undertaking. At 
Eastern Washington University, strong leadership on the part of the university's president 
and provost and a micro-computer based model have enabled the organization to take a 
giant step forward toward realizing that goal. 

The model placed a fairly sophisticated analytic tool in the hands of the departmental 
planners with which alternative strategies could be evaluated over a multi-year time frame. 
More importantly, by identifying and prioritizing budgetary allocations needed to support 
programs, the model required managers to make the same types of choices and decisions 
required in the budget process, thereby avoiding the most common pitfall of efforts to link 
planning and budgeting processes; that of failing to make difficult choices in the planning 
process, and then being forced to abandon the plans when the budget process requires such 
decisions. 
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Turning a Private Label Credit Card 
into a Multi-Function ID Card 

Thomas G. James 
Bill R. Norwood 
Florida State University 
Tallahassee 
Florida 



ABSTRACT 

Florid State University has implemented a card system that 
combines the best features of debit and !D card systems with the versatility 
of a private label bank card. An advantage of the approach is that all 
financial processing is done remotely at a bank charge card center. The 
VisaNet system provides the communications backbone, enabling standard 
credit card readers to be used, and cash withdrawals from bank ATM's 
throughout Florida. The system is flexible enough to handle standard debit 
transactions, enable data to be extracted from self inquiry terminals, support 
cashless vending transactions, provide an emergency notification system, % 
and serve as a complete University billing system. The system, known as 
Seminole ACCESS, was pilot tested on over 8,000 students during the Fall 
1990 semester. A variety of new and existing technologies have been 
successfully merged in the development of this system. 
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Turning a Private Label Credit Card 
into a Multi-Function ID Card 

Thomas G. James & Bill R. Norwood 
Florida State University 

Introduction 

The campus debit card system, in some circles, was the "in" system to install 
during the last decade. Many forward-thinking institutions, out of a desire to improve the 
business side of their campus auxiliary units, implemented debit card operations that have 
been very successful. For a variety of reasons Florida State University (FSU) was not 
among those institutions that chcse to move into the debit card arena in a big way. This is 
not to say, however, that we have not been trying; for we have been evaluating 
alternatives to our University photo ID since about 1984 and a Vali-Dine card system has 
been used for me^l plans for several years. 

We'd like to say that we were incredibly in touch with the technological trends 
shaping the debit card industry and that we were waiting for the precise moment to make 
our move. However, our basic motivation for waiting and studying, and waiting some 
more, was a lack of money. Although we will admit that after all of the committee work 
was done, our concept of what a card system should do for financial transaction 
processing had not been implemented in any existing campus card system that we knew 
of. 

Let's begin by listing some of the issues we felt were not adequately addressed by 
turn-key campus debit card systems, circa 1987. First, there was a requirement for 
additional hardware, software, and communication interfaces. Second, our existing 
administrative terminals, which were operating in a coaxial 3270 SNA environment, could 
not directly access the debit card system. Third, we anticipated substantial local staff 
involvement, initially and on a continuing basis, from both the information systems and 
financial units of the University. And fourth, existing systems were restricted to on-campus 
use and could not, for example, take advantage of the vast financial networks that exist in 
our community and state. 

No doubt many will feel that these issues are not insurmountable obstacles, and we 
agree. However, what was evolving on our campus was a much bigger concept for a card 
system. At the root of our search was the desire* to consolidate into a single system all of 
the financial transactions between a student and the University, as well as those non- 
financial transactions typical of photo ID usage. If a student chose to, essentially all goods 
and services on campus could be purchased or accessed with a University-issued card, and 
the student would receive a single monthly statement of account activity. Thus, FSU 
wanted a card system that could 1) replace the existing photo ID, 2) be used on or off 
campus, 3) generate a single consolidated monthly statement, and 4) directly interface into 
the University's financial systems. 

Our search for the ultimate card system led us to examine the benefits of using the 
services of a bank credit card processing center. As described in our presentation at 
CUMREC'90, we were able to evaluate the various processes by contracting with a bank 
card center to provide a billing system for the student long distance service offered by the 
Office of Telecommunications (OTC). 
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We were able to assess, for example, the following: 

1) establishing accounts for students 

2) generating and distributing cards 

3) generating monthly bills for multiple merchants 

4) collecting funds remotely at the bank card center and posting funds to 
University accounts 

5) establishing on-line terminal access to the bank card center host 

6} establishing internal control procedures using bank card center reports and 
control totals generated when data is prepared and transmitted from the 
University 

Debit Card Pilot Project 

When we left Buffalo last May, after presenting our paper to CUMREC'90, we did 
not know if the idea of implementing a debit card system would be accepted by University 
administration. We can truthfully say that taking what had been learned in the OTC pilot 
and turning it into a full-blown debit card system was only a dream of a few people at 
FSU. We fully expected it would take another year of discussions to move the project 
ahead, even though the pilot with long distance resale had been successful. 

Thus, you can imagine our shock when the concept was supported by the Vice 
President for Finance and Administration and we were given an opportunity to address our 
proposal to the University Executive Council. In a matter of days, the President endorsed 
the idea, appointed a steering committee and a project director, and established a 
$100,000 line of credit through our Auxiliary Service Board. But that was just the 
beginning. In a matter of a few more days, the Steering Committee had decided that a 
debit card pilot project would be developed and in place for the Fall 1990 orientation 
program, a mere 3 weeks away, and that it would be called the Seminole ACCESS card. 
Naturally, some of us implored the steering committee to slow down, pointing out that 
monumental problems could develop if all the details weren't sorted out properly. Our 
pleading, however, fell on deaf ears; the decision had been made. 

The pilot project which we implemented in August involved the following decisions 
and issues: 

Selecting the Target Population 

We chose to issue Seminole ACCESS cards to all new students, both freshman and 
transfer, attending FSU during the Fall 1990 semester, as well as all students who lived in 
campus residence halls. There were several reasons for selecting these groups. Because 
all students receiving the card were charged a $5.00 fee, whether they were going to 
deposit money in their account and use the debit card feature or not, the ACCESS Steering 
Committee felt that new students might be more receptive to the idea than existing 
students. All dorm students were included because they had previously been issued a 
card 'as part of the long distance resale billing project the prior year, and in order to 
continue the long distance resale billing system with the new debit card, all such students 
had to receive a new card. 

The total population selected to receive the Seminole ACCESS card was over 8,600 
students. Of that total, 2,109 chose to deposit money into their ACCESS account. 
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Determining Services to Offer 

Since the ACCESS card was to become a reality in just a few short weeks, we 
needed to make quick decisions related to what services should be offered. Because our 
concept of a universal card implied more than simply a debit card service, we felt 
compelled to expand the initial offering. Thus, access to the on-campus bank AIM, 
emergency notification, telecommunications billing services, and a self-inquiry terminal 
system were made a part of our pilot. 

We met individually with all of the offices concerned, and on August 19, 1990, just 
1 2 weeks after project approval, students were depositing funds and using their ACCESS 
card at over twenty different locations, both on and off campus. Off campus locations 
were restricted initially to two adjacent bookstores and the gift shop operated by our 
booster organization. 

Developing a Marketing Strategy 

Big advertising campaigns and TV spots were high on our list; our wish list that is. 
Actually, we ended up with a very targeted marketing campaign based on no budget and 
no lead time. Marketing included: 1) a simple letter to new students and parents just prior 
to their arrival for summer orientation, 2) group presentations at orientation sessions with 
parents and students, and 3) buttons and T-shirts worn by orientation leaders and staff at 
the Seminole ACCESS Center asking "Do You Have ACCESS ???". 

The marketing strategy was to explain where the ACCESS card could be used, 
emphasizing ease of use, the safety inherent in not carrying cash, access to cash in ATMs, 
a monthly detailed statement of account activity, the emergency notification system, and 
the personal attention shown at the ACCESS Center. Most students and parents were 
pleased with the idea of the ACCESS card program and felt that it would be a useful 
service. 

Establishing the ACCESS Center 

If one is to have a program like Seminole ACCESS office space is needed, and it is 
unsettling to be looking for office space that will create a professional image, and be 
centrally located to the resident student population, knowing that the doors must be open 
in a matter of weeks! Our problem was partially solved when we located a recently 
vacated storefront at our University Union complex. Since we were operating on a limited 
budget, how could we afford to rent office space? What about counters, computers, 
terminals, telephones? What about staff? Because of the many people anxious to see the 
ACCESS card succeed, the space, staff, and necessary equipment were made available in 
time to open the doors for the orientation sessions beginning in June. 

Converting Long-Distance Resale System 

After participating in the initial pilot of the billing system with the charge card 
center, our Director of Telecommunications decided to install a new system (BITEK) for 
long distance resale that provided several enhanced functions. The BITEK system would 
support, for example, a student deposit, and because it included a computer that 
communicated directly with the switch, student services could be terminated automatically 
when charges exceeded the deposit. The new system was a turn-key system, capable of 
handling all of the long distance billing functions on its own. Our goal was to 1) have 
BITEK staff modify their system to transfer data to and receive data from our local 
cashiering system as an interface to the charge card sysiem, and 2) make changes in our 
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cashiering system to produce files that would be downloaded to BITEK, as well as various 
supporting reports. 

After several false starts, we were successful in developing an interface to provide 
data on payments and deposits to the BITEK system so that it could activate and 
deactivate telephone service automatically. 

Determining Merchant Agreement and Discount Rates 

Naturally, determining who should pay and how much was a hotly debated subject. 
Discount rates charged to merchants that accept the ACCESS card are adjusted every 
three months based on the average sales price. The relationship between average sales 
price and discount rate is inverse. Thus, merchants with small average sales prices are 
charged higher discount rates than merchants with high average sales prices. Discounts 
range from 1.5% to 5% for campus merchants. Off campus merchants that accept the 
ACCESS card will be charged a discount rate 1 percentage point higher than on campus 
merchants. 

A critical H *.ot project task was the development of a merchant agreement that 
describes the responsibilities and obligations of the merchant and the University. Credit 
card Industry standard guidelines were followed but the agreement was tailored somewhat 
for the campus environment. 

Developing Local System Interfaces 

Our policy regarding the development of local system interfaces is very simple. Any 
financial transactions that are to be posted to ACCESS card accounts must be generated 
by one of the following; 1) ZON Jr. type readers operating through VisaNet in support of 
merchant sales activity, 2) charge transactions created from a batch system such as BITEK 
which are submitted (uploaded) to the charge card center through their cash letter 
processing unit, or 3) the University's cashiering system from student deposits or 
payments. 

Our intention was to force all activity through these three control points, eliminating 
the on-line posting of deposits or payments directly to the charge card center. With 
financial updating restricted, audit trails would exist in the University cashiering system or 
the charge center's cash letter system. Because of this approach, our local system 
interfaces were greatly simplified, and additional application interfaces could be added to 
the University cashiering system as needed. 

Seminole Access System Description 

Now that some background and an overview of the pilot project have been 
presented, let's examine the Seminole ACCESS System more closely. 

In-House System Enhancements 

Crossover Table - Interfaces for administrative applications residing at our 
administrative computing center were required. Access to student or financial records 
using the ACCESS card account number from the ABA coded magnetic stripe were not 
possible directly since most University records used social security number as a key. 
Thus, a crossover table was built to allow applications to use either social security number 
or ACCESS card number to locate records. 

Having built the crossover table, access to data from terminals with attached credit 
card readers was enabled. Self inquiry terminals at various locations throughout campus 
allow students with ACCESS cards to read and print course and fee information. In the 
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near future, this service will be expanded to allow students update access to our central 
address file. Concerns over security have been reduced since data is not accessed by 
entering social security numbers. One now needs an ACCESS card and a personal 
identification number (PIN) to use most self inquiry terminals on campus. 

Cashiering System - The FSU cashiering system was developed locally in CICS for 
use with 3270 type terminals operating on host based data files in 1987. This system 
was enhanced to be the control point for financial transactions related to the ACCESS 
card. All deposits or payments flow through this system. 

This system was modified to create transactions for downloading to the BITEK 
system in support of long distance resale. Thus, when deposits for the activation of long 
distance service or payments on the previous months charges are posted into the 
cashiering system, a separate transaction file is generated. Office of Telecommunications 
personnel then use a new CICS applications to further prepare this file for downloading. 
At appropriate intervals the file is transmitted to the BITEK system to update its internal 
files. 

Another local interface involved the addition of a billing address to the University 
centralized address file. The address file, together with any applications that needed to 
access this new address were modified. 

Charge Card Center Operations 

On-line Access - Once transactions generated in the cashiering system are 
transmitted to the charge card center, individual accounts can be updated through batch 
or on-line processing. On-line updates are processed directly at the bank center in Tampa, 
Florida. Since our cashiering system controls financial transactions, direct on-line account 
activity is limited to general maintenance functions such as requesting a new card, adding 
a new account, requesting a PIN number for ATM use, or updating statement addresses. 

Reports - Printed reports are produced daily at the bank center and delivered to the 
First Florida Bank in Tallahassee. A wide range of reports are available, including those 
used for account activity verification and review, merchant reporting, over-limit and late 
payment reports, audit trails and cash settlement reports. Microfilm copies of all reports 
are kept by the charge card center in the event of a lost report. 

Lost/Stolen Cards - One of the most important operational issues we faced was 
how to handle lost or stolen ACCESS Cards. In a normal University environment, lost or 
stolen picture ID cards are not a serious problem. In our case, the fact that students have 
money on deposit for use at over twenty-two different locations changed that situation, 
however, what was expected to be a difficult problem was one of the easiest to solve 
because the bank already has a system in place to handle such situations. 

In the case of a lost or stolen ACCESS card, the student is instructed to call a 1- 
800 number. This number is active twenty-four hours a day, seven days a week. When 
reported, the operator will ask for pertinent information, such as when was it lost, and the 
last time it was used. This information is electronically passed to the charge card center 
and within a matter of a few minutes, the account is immediately deactivated. 

To reduce losses associated with fraud, transactions coming into the system after 
the card is reported as lost are monitored. When a possible fraudulent transaction enters 
the system, the bank center calls the card holder to determine if they made the purchase 
in question. If they indicate they did not, the transaction is considered fraud, noted, and 
not billed to the customer. 

Collections - Collection processing is important for two reasons. First, it is possible 
for a student to issue the ACCESS Center a bad check and then remove or spend most of 
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the funds. Second, Telecommunications is actually allowing a student to run up a credit 
balance for telephone services. Thus, should these situations result in a bad debt, the 
University has access to the collections system used by the bank. This system will allow 
collectors (bank employees) to work through prompted screens bringing up accounts that 
are in various stages of delinquency review calls and send letters automatically. 

By consolidating the financial transactions between the University and the student 
into a single system, we can make much better use of non-payment information. The 
ACCESS card system makes it much easier to place financial stops on students that owe 
the University money. 

Merchant Authorization - Perhaps one of the most intriguing parts of the system is 
sales, or authorization, processing. When a purchase is made at the University Bookstore 
on campus, the ACCESS card is swiped through a credit card reader. The credit card 
reader then routes the account number, amount of the sale and a merchant identifier to 
VisaNet. VisaNet determines the card processor, in our case First Florida Bank Charge 
Card Center in Tampa, and routes the transaction accordingly. The STRATUS computer at 
the card center reviews the "buy line" of the account and, if sufficient, reduces it by the 
amount of the purchase. Concurrently, a record is made of the authorization. When this is 
completed, an authorization code is added to the transaction and routed back to VisaNet, 
which then routes the transaction with the authorization code back to the University 
Bookstore. 

Should VisaNet fail, transactions will be routed to the National Data Center (NDC) in 
Atlanta which will route them to Tampa. If STRATUS in Tampa is down, ACCESS 
transactions cannot be processed. Since we are dealing with a debit card, no credit 
purchases can be authorized. We are discussing, however, setting default parameters at 
NDC to allow students to spend up to twenty-five dollars in the event the system is down. 
This would allow, for example, a student expecting to use the ACCESS card for breakfast 
to do so when the system was not available. ATMs have separate default parameters and 
are expected to remain at zero. 

Emergency Notification - An additional feature worth mentioning is emergency 
notification, in the event of an emergency, the bank center, upon notification, will flag the 
student's account in the STRATUS system. Subsequently, when the student uses the 
ACCESS card, a "call" message will be routed to the appropriate credit card reader. In our 
case the student will be instructed to call the FSU Campus Security Office for a message. 

Fund movement - To move funds from various accounts, the charge card center 
uses a system known as the Settlement system. The Settlement system receives detailed 
transaction (sales) data from NDC daily. Included with the sales information from 
merchants are cash letters covering how much money is due to be transferred to 
merchants for their daily sales activity. 

In our case, we are allowing the charge card center to move funds directly from 
various accounts as indicated by the Settlement system. Funds deposited by students are 
placed in an agency account at a local bank. Funds are then transferred from this account 
and deposited either to another FSU auxiliary account or to another bank. 
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ACCESS Card Benefits 

We believe the entire campus will benefit by using the Seminole ACCESS card. 
Students are now able to pay for most campus services with one common card, reducing 
the need for checks, cash, and credit cards. This also leads to a cashless environment 
that promotes safety and may reduce thefts. Students also receive a detailed statement 
showing all of the uses of their card. Parents will be able to relax knowing that the check 
they sent has been deposited and they can see where their money was used. Funds are 
available to use sooner than through a normal checking account. Parents know that in the 
event of a family crisis, the emergency notification system is available to help locate their 
son or daughter. 

Departments can also reap benefits from the ACCESS card. FSU has received 
numerous audit criticisms for the 80 + cash collection points scattered across the campus. 
Most of these departments are too small to have the necessary separation of duties 
required to satisfy an auditor. In some cases, one person handles billing, collecting, and 
balancing. Thus, departments in which these conditions exist can now meet audit 
criticisms by using the ACCESS card. All collections from students at the department level 
can be handled through credit card readers. When cash and checks are not accepted, 
audit criticisms are eliminated. An additional benefit is that staffing requirements and 
workload are also reduced. The equipment needed to support departmental collections 
consists of a standard credit card reader and attached printer. 

Academic and auxiliary departments are now able to charge student accounts for 
services, lab breakage, losses, etc., without collecting cash or completing various forms to 
be sent to the Cashiers office. The Controller's Office now has fewer cash collection 
points to worry about and charges are posted to student accounts immediately. 

Certainly, one of the hardest problems to deal with at any University is the 
collection of tuition. At FSU this means hiring approximately 50 temporary workers for a 
week; moving thirty or more computer terminals to a central location; and having 30,000 
students line up over a five day period to pay fees. 

Plans are now being developed to allow students to authorize tuition and fee 
payments from their ACCESS account while using the telephone registration system. If all 
goes as expected, students will not have to go to a central point to pay fees, which will 
save the University money and be very convenient for students. 

Funding Methodology: Who Pays? 

In order to properly consider this topic, one must recognize that campus operations 
can be categorized into two types: those that generate revenue to pay processing costs, 
and those that only generate costs. We refer to these as revenue generating and non- 
revenue generating operations, respectively. 

Revenue Operations 

Revenue operations are those where goods or services are purchased. These 
operations include fast food outlets, cable TV and long distance telephone services, 
bookstore sales, computer store sales, ticket sales, etc. These are the areas where we 
expect to recover the cost of the ACCESS card system through the use of a "discount 
rate." If a merchant accepts Mastercard or any other type of bank card as a means of 
payment, a percentage, or discount rate, of the sales ticket is paid for processing. Funds 
generated from revenue generating operations should pay for their operational costs, but 
they should not pay excessive discount rates In order to subsidize non-revenue operations. 
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Non-Revenue Operations 

If the costs associated with non-revenue operations are not recognized and 
accommodated, then funding the ACCESS card becomes difficult. By non-revenue, we 
mean any operation that uses the ACCESS card for other than financial processing 
purposes such as taking class attendance, authorizing admittance to University functions 
or participation in intramural athletic programs, or determining the current status of a 
student. These operations generate costs, and since every student, faculty, and staff 
member will eventually be required to have an ACCESS card, non-revenue uses of the card 
will increase. Thus, base funding requirements for the ACCESS card must cover the added 
costs of the non-revenue generating operations. 

At the present time, we are using the $100,000 auxiliary credit line to fund 
ACCESS card costs related to non-revenue operations. However, many of the processing 
functions of non-revenue operations can be done without incurring additional transaction 
processing costs at the bank card center. For example, data can be downloaded from the 
bank card center to personal computers for use in access or student verification 
applications such as athletic ticket sales or class attendance checking. While there are 
opportunities to avoid costs in handling non-revenue operations, there are costs associated 
with these functions the University must be willing to accept. 

Discount Rates 

Since Florida State University is the M issuer H of the ACCESS card the University 
determined the discount rate, as well as where the ACCESS card may be used. During 
this analysis, it was determined that the discount rate table had to be a sliding scale based 
on the average ticket sold by a merchant. The rate was based strictly on the per 
transaction cost associated with processing sales transactions from merchants. A 
merchant can expect to pay a discount rate of as little as 2% or as high as 6% on 
ACCESS card transactions. 

Conclusion 

The ACCESS card pilot at Florida State University which was based on the concept 
of a private label bank card was successful. We have attempted to maximize use of the 
card on campus, and we have made available the state-wide network of MAX ATMs. 
Students may withdraw cash at any of 250+ locations using their ACCESS card and PIN 
number. This is a critical factor in the success of the operation. Without access to cash, 
a student would not be as likely to leave funds on deposit in their ACCESS account. 

Initial projections indicated deposits would total approximately $250,000 after the 
first three months of the project. Actual deposits totaled over $1,100,000 for this period, 
with merchants receiving over $530,000 dollars in sales. Thus, deposits were almost 
400% greater than expected. Students have utilized the MAX ATM network for cash 
withdrawals amounting to $250,000, and the ACCESS account currently has a deposit 
balance of over $220,000. 

Due to the increased level of deposits, we have also generated more income from 
sales. This has amounted to approximately $11,000, with $10,000 coming from the 
merchant discount rates. ATM withdrawals generated approximately $1,000 dollars in 
revenue. 

At Florida State Univers* :/, our campus card system solution is based on the merger 
of several technologies. The tools available in the private financial sector are powerful, 
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reasonable in cost, and waiting to be used. We are now in the process of merging the 
following technologies to further support and enhance our card system: 

First Florida Bank Center will provide the backbone of the financial network for 
debit, ATM, hardware, software, and merchant support. 

DATACARD Corporation will provide the technology for the new digitized 
photograph for the ACCESS card. This will include on-site card creation and encoding of 
the ABA encoded magnetic stripe, as well as storage of the digitized photo for future use 
in a variety of innovative applications. 

DEBITEK Corporation brings the "cashless transaction" environment to the ACCESS 
card for all vending operations. This is a key part of the FSU solution because it allows us 
to avoid the transaction cost of the banking system for handling small ticket operations for 
which a discount rate would be prohibitive. Even more importantly, it gives us a vehicle 
that can also be used in off-campus privately operated businesses such as local copy 
services immediately adjacent to the campus. 

TELZON Corporation enables hand-held magnetic stripe readers to be used to check 
attendance in large lecture classes, or check participants in intramural activities to 
determine if they are currently enrolled. 

BITEK Corporation is usually a self-contained monitoring, billing, collection, and 
accounting system for various services such as long distance resale, cable TV, etc. 
Because of the single bill concept, interfaces to our cashiering system have been written 
allowing full integration of the two systems. Financial functions are handled outside of the 
BITEK system, but the BITEK system feeds charges to ACCESS, and is in turn fed 
information to automate the activation and deactivation of services. 

Our goal is to apply these technologies, and the concepts behind them, to develop a 
universal card system. At Florida State University the Seminole ACCESS card truly 
integrates financial processing, and redefines the meaning of access to University services. 
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Attributes for good executives are outlined in detail. 
The vision you must have to change the organization must 
be a high priority of your job. The professional 
credentials that are required to do your job and how you 
are able to establish your professionalism in a higher 
education setting are discussed. The management ability 
you must have including, people skills, types of 
supervision, and the relationship to power both personal 
and organizational are reviewed. The executives role in 
establishing a good management team are considered. 
Finally, attention is given to critical components of 
managing and controlling change within the organization. 
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Introduction 



In this review of the characteristics, skills, and attributes 
required of the computer and information managers in higher 
education, the starting point is to examine the credentials of 
these professionals as well as the historical development of the 
position in higher education* 

Origins 

Not unlike the emergence of librarians, bursars, and 
registrars from the ranks of the faculty in the colonial colleges 
of America, faculty were the first managers of computing resources 
on college and university campuses. Indeed, the early computer 
scientists and mathematicians were pressed into service on a part- 
time basis to assist with the basic data processing that the 
business office required to conduct the transactions of the 
institution. However, as the complexity of the data processing 
increased the position became permanent. Soon the need to provide 
services in support of research and instruction became part of the 
service requirement. This expansion was often met by creating 
separate academic computing centers. Today we have instances of 
campuses with combined centers as well as those with separate 
facilities. Reporting lines are equally complex with the majority 
of facilities still reporting to a finance or administrative 
officer. Indeed this early association with administrative 
functions rather than academic endeavors may have been the main 
reason that the computer or IS manager rarely enjoys faculty status 
like his colleague in the library. This comparison with library 
director will be revisited later since there is similarity in the 
provision of academic services provided by these professionals. 
Turning from the past to the present, who is performing the task 
of computer and IS management on our campuses? What type of 
academic credentials are needed? How important is professional 
certification? 

Charles H. War lick of the University of Texas provides the 
most comprehensive body of information about the IS manager in 
higher education through his editing of the annual Directory of 
Computing Facilities in Higher Education and the companion Salary 
Survey - Academic Computer Facility Directors. In the 1990 
edition, Warlick profiles the average computing facilities director 
as being forty seven years old, with six years of service as 
director, and having earned their last degree fifteen years ago. 
The types of degrees are varied with just less than half of the 
highest degrees earned by directors being in computer science, 
mathematics and the physical sciences. Business degrees were 
numerous but still less than the combination of other types of 
degrees earned. This diversity of academic background may be 
viewed as a positive or negative factor in evaluating the 
credentials of the IS professional. Can "anyone" become a computer 
center director and if so is that a good thing? 
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Perhaps it would be useful to return to the comparison of IS 
professionals and their colleagues in the library. A library 
director is usually expected to have very specific academic 
credentials. A masters degree in library science (MLS) from a 
school accredited by the American Library Association is usually 
a prerequisite for employment. Does the lack of similar academic 
credential disadvantage the IS professional or does the diversity 
of educational background provide higher education with a better 
prepared pool of professionals to manage IS facilities? This 
question may be tested as the convergence of computing and library 
services continues as information services are reshaped on 
campuses . 

Professional accreditation may be one way of off setting the 
lack of specific academic credentials. However, a closer look 
would suggest otherwise. Certainly there are professional 
societies that serve the IS professional. The Association of 
Computing Machinery (ACM) , and the Computer Society of the 
Institute of Electrical Engineers (IEEE-CS) are primary among IS 
professionals in higher education. The Data Processing Managers 
Association (DPMA) also has impact but still seems to be dominated 
by members from the private sector. These organizations invite 
membership without specific qualifications and are complimented by 
other voluntary organizations like CAUSE. 

However, there is an accreditation program which is 
administered by the Institute for Certification of Computer 
Professions (ICCP) which has been formed by eleven professional 
societies including the three previously cited. This certification 
process is done by a combination of testing, job experience and/or 
academic training. The three designations offered are: Certified 
Data Processor (CDP) ; Certified Systems Professional (CSP) ; and the 
Certified Computer Programmer (CCP) . Despite this established 
method of certification and recertif ication, it would not appear 
that much attention is given to such certification in the 
recruitment of IS professionals in higher education. At least, it 
would not appear so by the review of position announcements. 

This paper offers no specific position on the question of 
certification but simply reviews the current situation to show what 
professional credentials the IS manager can point to and how they 
compare with their academic colleagues. 

Academic Colleagues 

The continually developing maturation process of information 
technology on our campuses has not provided a shortage of those 
who are willing to play a part in providing services or formulating 
related policies. Certainly, IS managers cannot assume that 
information technology is solely their domain. Others are playing 
a part and will continue to vie for resources and responsibilities. 
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Faculty, particularly those in the computational and 
quantitative sciences have long been an alternate source of 
expertise to support or contest the level of services and expertise 
offered by the IS manager. It would not be far fetched to suggest 
that many campuses may have found their Computer Science department 
and computer center to be out of synch from time to time. As 
stated earlier many IS professionals may have come from the 
faculty. However, many would attest that the perception of them 
by former faculty colleagues can change. This situation has been 
expanded to include faculty from many different disciplines who 
were quick to adopt the personal computer as a teaching or research 
tool and have not only mastered it but may be able to develop a 
greater body of computing expertise within the narrow focus of 
their discipline. 

Library directors have begun to emerge as strong competitors 
for resources and responsibilities in the provision of information 
services. It should also be noted that equipped with strong 
academic credentials, frequently accompanied by faculty status, 
they may be formidable allies or powerful rivals. The convergence 
of computing and library services through electronic information 
exchange will provide a sharp focus on the relationship between the 
Library director and the IS manager. 

In addition to these more traditional academic colleagues, 
the latter part of the 1980* s has seen the emergence, or at least 
the partial emergence, of the Chief Information Officer (CIO) even 
if many carry out the coordinating of information and technology 
related services and policies tmder a different title. A CAUSE 
professional paper recently provided a comprehensive review of this 
phenomenon . The Chief Information Officer in Higher Education ; 
Penrod, Dolence, and Douglas; CAUSE Professional Paper Series, #4. 

Finally, we should not overlook the student body. Their 
perception of the IS manager has traditionally been one of a 
service provider, a gate keeper, a part of the administration. 
The more technologically advanced student may have more elaborate 
expectations and provide new challenges for those charged with 
managing, securing, and maintaining information and computing 
services. While it may be unnecessarily paranoid to think of a 
campus, nation, or world full of hackers with the primary objective 
of illicitly accessing data or computing resources you have been 
charged with protecting. It is quite clear that networking and 
related security measures are more critical now than ever before. 

So what does this mean to the IS professional. First and 
foremost it means that it is more important than ever to act in a 
professional manner and to be sure to remember that there will be 
a need to accentuate all aspects of professionalism among their 
management team and staff, if they are to continue to play a 
leading role in the provision of services and the establishment of 
appropriate policies and procedures. In other words it may not 
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continue to be business as usual or things that were held to be 
self evident in the past, may be under new examination. The 
remainder of this paper deals with how the IS professional can best 
use professional tools to deal with the challenges of today. 

Vision 

In today 1 s environment, Information System Managers must be 
seeking new ways to do business. "If it runs, don't change it, M 
isn't good enough anymore. The manager that does not create the 
environment for change may be a liability to the organization. 

Today's Information Systems (IS) Manager must keep up with 
the trends in today's technology. He must know the way his 
institution conducts their business and have the vision on how to 
transform the way they do business. A good manager must also find 
new ways to turn out effective managerial information systems. 

If the IS Manager does not have vision, then someone else in 
the organization may have this, or he can visit other institutions 
to gain this critical information. Today's top Information System 
Manager must become directly involved in the planning and 
implementation strategy for strategic systems. Keeping up with 
technology is critical to the success of information systems. 

Choosing what is Important 

Picking a strategic system is the most important function we 
can play. A university has many goals and objectives, and the 
systems v;e implement are a means to an end, namely to achieve these 
goals. Picking the right system is sometimes known as a critical 
success factor. Hence, the projects we select are essential in the 
support of achieving these goals. The system we choose must be 
visible from the top yet support the operational functions that run 
an institution. If the system we pick is not visible from the top, 
then we may have a hard time explaining what we accomplished for 
the year. 

A good example of a strategic system or subsystem might be 
automating student refunds, thus producing faster turnaround for 
student refunds or telephone registration, thus reducing long lines 
for registration. Both are very visible from top and bottom. 

Do we slice off a piece or phase in the project? Many 
projects go down the drain due to two or three year target dates 
with nothing visible to the user; hence, a loss of confidence in 
the computing organization. It is always best to design from the 
top down and build from the bottom up whenever possible. Thus, 
picking a piece or a phase when the user can visibly see some 
tangible output is important. 

Once we pick a project and get the go ahead, then matching 
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the right resources to the job is essential. This requires an 
understanding by management of picking the right people to get the 
job done- Do we place three "drivers" on the project, who will 
fight each other for control, or three "amiables", who must be 
stroked each day before they can work. Do we control the 
"enthusiast", who starts everything but finishes nothing? Matching 
the right resources to do the project is a skill we rarely give 
much thought, yet it is a critical factor to the successful 
completion of the project. 

Do we get the job done or study the project forever? You can 
study the project for six months and program for six months for 95 
percent of the goal or you can study the project for three months 
and program for six months to support 90 percent of the goal. 
Defining the project may never end. One must make a reasonable 
decision to proceed after lengthy discussions with the user in 
defining the system. 

Cross Organizational Issues 

When we get to the roadblocks, do we address the cross 
organizational issue or hope our subordinates can hit their heads 
against the wall until it cracks. It is the Information Systems 
Manager who is responsible for compromise and solutions. 

Do we stand up for our staff, fight for our beliefs or back 
down and let others make our decisions. It is up to us to sell 
ourselves and our ideas. This comes about through doing what we 
say we are going to do and meeting our deadlines and obligations. 

Acting as a Change Agent 

A crumpled piece of paper with letters clipped from newspapers 
and magazines spelled out the following message in a prominent 
advertisement : 

We have the information, and getting it back will cost you! 

We may laugh at this portrayal of the world of computing, and 
yet, are we still perceived this way by the people we are trying 
to serve? If we are not good change agents, the answer to this 
question may 'oe "Yes" in all too many cases. 

Are we good change agents? If we look at current articles and 
our speeches and casual conversation we seem fairly convinced that 
we are not good change agents. We are the ones who know the 
technology, who struggle to keep up with it and who continue to try 
to educate other people. However, we are also the ones who 
continue to discuss how the people we try to change keep resisting. 
They don't want to change. Perhaps the problem still sits with us. 

Good change agents must focus on the needs of their 
institutions. Yet, where is our focus? We have services to 
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maintain and build and more than likely we are still highly focused 
on the technology itself, not on thr problems of our colleges and 
universities* We can test ourselves by looking at what we read, 
who we talk with, and what we talk about* 

- Are we limited to Computerworld, Datamation, Super computing, 
MacUser and the computing section of the Chronicle of Higher 
Education? 

- Are we spending most of our time with other technology 
oriented people? 

- Are our conversations about upgrades, capacity problems, 
project development deadlines, and the merits of one computer 
manufacturer versus another? 

If so, how well do we understand the people we are trying to 
serve? How can we have a balanced overview of their needs and 
those of the institution itself? How can we say we have the right 
answers when its possible we are not even addressing the right 
problems? Is it any wonder that we find it difficult to make the 
changes we feel are necessary and to get the funding to make those 
changes? 

Good change agents must be willing to change themselves* In 
this regard, we, as computing professionals, are as resistant to 
change as anyone else. Cutting someone else's budget to fund out 
technology is okay, but cutting the central computing budget 
(assuming you are in central computing or networking) to fund 
departmental machines or local area networks is a different story. 
If we have a negative reaction, it is based upon knowledge of the 
institutional problems and proper application of technology or is 
it based upon loss of control, downsizing of our importance, or 
other personal feelings? 

Good change agents must know themselves. We cannot start to 
change ourselves or our institutions until we are willing to really 
look at ourselves and know who we are and what we really have to 
offer. Most of us don't really know ourselves. We have developed 
some wonderful defenses that allow us to be comfortable enough and 
confident enough to function. Very few of us will drop all of our 
walls, but if we are still learning about ourselves, we are on the 
right track. 

Good change agents listen. One of the ways we learn about 
ourselves, the problems of our institutions, and the problems of 
the people we are trying to serve is to listen. Much has been 
written about good listening skills and much of it is sound advice. 
It boils down to one thing: We cannot learn while we are the ones 
doing all of the talking, about ourselves and about our 
technologies . 

Good change agents market themselves. On one hand, we cannot 
do all of the talking. On the other hand, we cannot afford to be 
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silent, either. In tandem with listening to problems and knowing 
our worth in solving those problems, we must communicate that worth 
to our institutions. Information technologies may indeed be the 
keys to solving several of the major pressing issues for education. 
However, if we are not getting the messages out and being heard by 
the right people, those may not be seen and put to use. 

Marketing is not just selling; it involves all of the 
attributes mentioned above. Marketing involves listening to the 
needs of the people we serve, understanding those needs, knowing 
what resources and skills we have to apply to meet those needs, 
changing our combined resources an skills if required, and then 
coming to an understanding or contract with our "clients" to 
deliver the necessary services. 

Good change agents are leaders. A leader is proactive, not 
just reactive. As change agents we cannot afford to sit back and 
wait for problems to come to us. Enough of them do on their own, 
and we end up spending time solving them. But perhaps many of 
these problems are better left unsolved. A good change agent works 
to get an overview of what the right problems are and works to 
solve them. This is not easy because all problems cry for 
resolution. 

Good change agents accept responsibility wisely. Problems 
related to computing, even large administrative systems, do not 
necessarily belong to computing centers. We do not have unlimited 
resources, therefore it is understandable to think that we can 
solve all problems. More importantly, computing centers should not 
own administrative systems. The users who are served by the 
systems are the rightful owners and must accept the 
responsibilities that come with it. The responsibility for 
choosing which problems to solve must sit with the college or 
university as a whole. Upper level computing managers who accept 
the wrong responsibilities without adequate resources are destined 
for trouble. Sometimes we can best lead by helping others accept 
responsibility . 

Ability to Manage 

The functions we are hired to do are no more than what we 
learned in Management 101; that is, we plan, organize, control and 
supervise. 

The skills we need to do the job are still the same; namely, 
people, technical and administrative. Most of us are promoted with 
one or maybe two of these skills. What about our people skills? 
What type of a manager are you? In the decision process of 
planning, are you a participative manager or do you use benevolent 
participation? Do you listen but make the decisions no matter what 
your subordinates say? Do you make decisions, and are they timely? 
What style of leadership do you use? Do you use all four styles 
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available; namely, do you tell people what to do, sell your 
subordinates on what and how they should do it, ask how they would 
do it, or just tell them to go do it. 

Each one of these styles is important in getting the job done, 
and each style depends on the maturity level of the subordinate. 
As managers we must deliver on what we say we will do, if our users 
are to have confidence and respect for our ability to get the job 
done . 

Executive Ability 

The ability to work with others in the organization at your 
level and above is vital to the success of the Information Systems 
Manager. Do you make periodic visits to the Deans, Department 
Heads and Vice Presidents? Do you know your peers? Remember we 
make most of our decisions in an informal setting. 

The ability to sell our plans and decisions is so dependent 
on our abilities to influence those above us. 

Good executives admit their mistakes to their subordinates 
and are not afraid to correct their errors. 

The ability to broaden your horizons and gain the ability to 
be a good executive can be helped by actively participating in a 
professional organization. 

Conclusion 

Good IS Managers make change the rule rather than the 
exception and spend 40 percent of their time on creativity and 
looking at the way the institution does its business. They hire 
good managers and keep the organization lean and flat. It is to 
their advantage not to keep employees in the organization that 
cannot produce. No one can afford it. 

IS departments that survive the 90 *s are managed well. Where 
and to whom a department reports is minor compared to how they are 
managed. The reporting line of a department has very little to do 
with the department functions. Good managers make things happen. 
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Abstract 

In university administrative computing environments, the number of "urgent and essential" 
projects often far exceeds what the computer staff can design, program, and implement in a timely 
fashion. The problem is particularly acute when the backlog of such projects has grown significantly 
due to delays from an extended period of hardware conversion. Following a history of uneven and 
ad hoc approaches to allocating computing resources, a medium-size independent university is 
developing a more systematic, open, and fair method of evaluating, selecting, and setting priorities 
among such competing projects. This paper defines the problem, discuss the inadequacy of past 
approaches, and outline new methods which are being developed. 
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Introduction 

An ongoing challenge in most university administrative computing environments is that of 
balancing a seemingly unlimited demand for programming and system development with limited 
staffs of programmers and analysts. In the eyes of deans, directors, and other administrators relying 
upon computing to carry out their duties, their own particular projects are usually seen as "urgent 
and essentiaT needs which must-in the interest of the institution-move to the front of the queue 
and be addressed immediately. 

Beyond the issue of which projects come first, the sheer number of projects in the queue 
also can be a cause for concern. Even if there is agreement on the order in which projects should 
be addressed, requested work can so far exceed the programming capacity that the end of the queue 
would move many years into the future if nothing were done to limit the number of projects. 
Consequently, there is a need to determine which projects will be done at all as well as to establish 
a priority order among accepted projects. 

There are basically two approaches which can be used to control the volume and priority of 
computing requests. One is through a system of billing or "chargebacks/ 1 Charging for services 
imposes a form of marketplace control over computer utilization and the allocation of computing 
resources. If users are billed, only those who can afford the cost of programming or system 
development can get their projects in the queue; those with the largest budgets will typically be the 
first in line with the largest projects. Under such a system, however, there may be little relationship 
between whether a project is "affordable" and its actual importance in terms of broader institutional 
needs. 

The second means of setting computing priorities is through a centralized process in which 
each proposed project is reviewed in light of computing resources and institutional goals as well as 
its importance relative to competing projects. Such decisions are sometimes placed solely in the 
hands of the administrator in charge of computing, but more often a committee is involved. The 
committee approach has two majc* advantages: (a) it provides broader input of both information 
and perspective into the decision process, and (b) it provides a greater degree of legitimacy for the 
process and thereby should lead to wider acceptance of the decisions. 

This paper focuses on these two approaches to resource allocation in administrative 
computing. After a brief review of some of the recent literature on the subject, it will describe the 
problems in computing resource allocation experienced by one medium-size independent university 
and outline changes currently underway to address those problems. 

Patterns in Setting Priorities 

As many authors have noted, each institution's particular organizational structure for 
information technology should reflect the campus culture and traditions as well as the strategy it has 
chosen to achieve its goals (Barone 1987; Blackmun, Hunter, and Parker 1988; Dillman and Hicks 
1990). Consequently, it often is futile to simply try to impose one institution's structure on another. 
Many of the same forces are acting upon different institutions, however, and each can learn from 
the experience of others. With no pretense of being exhaustive, the following paragraphs will 
illustrate the major themes under discussion by examining trends, weighing arguments, and looking 
at the experience of others in grappling with these issues. 
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A pproaches to Computer Billing 



Institutions of higher education fund campus computing in a variety of ways. At one end is 
the "library" model in which all computer costs are budgeted centrally and there are no chargebacks 
to users. At the other extreme is the "economic" model designed for full recovery of costs from the 
users. Between are a number of variations involving some central funding combined with a partial 
recovery of costs through billing users. 

Discussions of billing for computing services often focus upon the issue as a problem of 
funding the cost of computing (Alley, Shaub and Willits 1987; Robinson 1988). As the same 
amount of institutional money usually is involved whether it goes directly to the computing budget 
or gets there by way of the departmental budgets of users, however, the issue really is one cf 
allocation of resources. It is computer billing as a means of allocating computing resources and 
determining priorities among competing projects that is of interest in this paper. 

Billing for use of computing resources has always been more common in administrative 
computing than in academic computing. The larger the institution, the more likely also it is to 
follow the chargeback approach. Billing was quite common in the 1970s, and a 1980 CAUSE survey 
found that between 1976 and 1980 there had been an increase in the percentage of institutions 
which were charging users for computer services (Thomas 1981). 

In the 1980s, however, there has been a trend away from billing for administrative 
computer services. A 1984 survey of small institutions found that the prevailing pattern was not to 
charge users for computer resources, either on a real dollar or a cost accounting basis (Coughlin 
1986). In the 1985 CAUSE survey of member institutions, only about 40% indicated that they billed 
for administrative computing costs, down from 60% in the 1980 survey (Thomas and van Hoesen 
1986). Larger institutions were still more likely to charge, but even among large institutions the 
percentage not charging doubled to 33% over the five-year period whereas among medium-size 
independent institutions the percentage not charging went from 38% to 75%. Results from the 
1990 CAUSE survey are not yet available, but there seems to be no indication of a reversal of this 
trend away from billing. 

Advocates of the chargeback model as well as institutions which follow that approach 
usually are sensitive to adjustments which are needed to make it work. In arguing the merits of 
billing for computer resources, for example, Chachra and Heterick (1982) emphasize that if this 
approach is to be successful the charges must be realistic, equitable, and predictable. In describing 
an institution which made a recent decision to move from central funding to 100% cost recovery in 
the area of administrative system development, Bushnell and Heller (1989) note that the change 
was made in phases and was accompanied by the transfer of funds to the budgets of user 
departments based upon historical patterns of usage. 

Some institutions have attempted to address the issue of chargebacks and priorities from a 
middle ground position. This involves establishing a basic level of computing service which is 
centrally funded and provided to the entire campus community with no individual department or 
program charges. Computer usage above this base level is considered to be incremental and 
discretionary and the individuals or departments are charged for such services. In describing this 
approach, Orcutt (1986) notes that in addition to providing an equitable means of controlling the 
level of usage, this approach stimulates a comprehensive and strategic approach to the use of 
computing and helps create an awareness of what a university expects from computing and what 
limits it might wish to enforce. 
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But as noted above, more and more institutions are choosing not to charge at all for 
programming or for computer usage. In describing one institution's recent decision to forego the 
chargeback approach, Bent and Enright (1990) point out that charging campus users would not 
generate any more money in support of computing while it would reduce the flexibility of the 
administration in assigning resources to the most important projects. In addition to the findings of 
the five-year surveys, the popularity of central funding for administrative comp uting can also be 
seen in many of the "Campus Computing Environment" features in CAUSE/EFFECT in recent 
years (Grinnell College 1988; Hamilton College 1989; McMaster University 1988). 

Guiding Computing by Committee 

Democracy has come to computer decision-making on most campuses. As computers have 
become increasingly important to both academic and administrative activities throughout the 
campus and as microcomputers have served to both decentralize and demystify computing, more 
and more constituencies both need to be involved and insist on being involved in computer-related 
decisions. 

This growing involvement of users has coincided with a trend toward consolidation of 
control over computing and other information technology at higher administrative levels (Plourde 
1986). Although at first glance these may seem to be contradictory trends, they can in fact be quite 
complementary if they evolve in a coordinated way. In analyzing the potential as well as the pitfalls 
of setting up a "computer czar" on campus, Fleit (1986) outlines several preconditions which should 
be present in the institution if such a position is to be effective. One of these is that the institution 
have in place a sufficient number of well-functioning computer advisory groups, "staffed by people 
who know what's best for themselves as users and who can take a broad look at what's best for the 
institution. In other words, the school should not look to concentrate power in the hands of a single 
individual" (p. 30). 

There is one dilemma which confronts institutions as they establish committees for 
planning and setting priorities in administrative computing. This derives from the fact that the 
users who are generally closest to the computing needs and therefore are often in the best position 
to provide the most valuable "input" typically are mid-level or lower in the institution's 
administrative structure. They have the insight as to what is needed, but lack the power to bring it 
about. On the other hand, those at the presidential and vice presidential levels have the power but 
may be quite removed from the day-to-day aspects of computing on campus. In recognition of this 
situation, institutions often have set up two-tiered committee structures. 

There are many examples of this type of two-tiered committee structure (Barone 1987; 
McMaster University 1988; Wenger, Gualtieri, and Leninger 1987). The specific committee 
structures, membership, and responsibilities differ from one institution to the next, but some quite 
common themes run through most examples of this approach. The lower-tier committee typically is 
composed of administrators such as the registrar, directors of admissions and financial aid, 
controller, purchasing director, and other middle level administrators whose operations are heavily 
dependent upon the administrative computing systems. This committee is often quite large and 
broadly representative. In addition to facilitating the two-way flow of communication between the 
users and the computer staff, committees of this type frequently *'e asked to review requests for 
programming and system development as well as to help with long-range planning in the area of 
computing. 
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Recommendations from this committee typically are then passed up to the vice presidential 
level. Whether as a formal computer planning and policy committee or as part of the tasks of a 
more general president's cabinet, decisions regarding the allocation of computing resources as well 
as the final voice in planning and major hardware acquisitions will generally come from this level. 
In some instances, the president also becomes involved at this stage. 

Indicative of the growing importance placed upon an effective committee structure in 
university computing is its centrality in a set of guidelines developed recently by CAUSE and 
EDUCOM. Designed to help institutions in evaluating their information technology resources— 
both self-initiated evaluations and those in response to accrediting agencies— the guidelines expect 
that "appropriate structures, such as user and policy committees, exist to provide guidance for the 
planning of the institution's information technology resources and services" (Evaluation Guidelines 
1988). 



One Institution's Experience 

With that brief review as background, the remainder of this paper will examine the past 
experience and current plans of one medium-size independent university in dealing with these 
issues. The university's main campus, which is the focus of this paper, has an enrollment of 3,800 
students and offers programs in the arts and sciences and in a number of professional areas. 
Degrees are awarded at the baccalaureate, first professional, masters, and doctoral levels. 

Administrative computing until recently was under the control of the financial vice 
president. The management and staff of the computer center tried to take a universitywide 
perspective and were generally responsive to the needs of other administrative users on campus. It 
was always clear, however, that administrative computing was run by the financial side of the 
university, that decisions regarding direction of administrative computing were made there, and that 
projects from that sector usually received highest priority. This advantage was compounded by 
differential billing practices and the absence of an organized users group. 

In 1985, the university began a period of hardware conversion in administrative computing 
which ended up lasting more than four years. As the initial conversion dragged on and on, delayed 
in part by unforeseen problems of package implementation and in part by what seemed to be an 
unending escalation in hardware needs and costs, the campus grew increasingly frustrated with the 
whole area of administrative computing. In early 1989, a new president decided to move 
administrative computing over to the academic vice president, who for more than a decade had 
overseen academic computing on campus. The academic vice president and the director of 
computer services were asked to assess the problems in administrative computing and to make a 
recommendation on how to proceed. After several months of consulting intensively both with 
major users and with vendors of hardware and software, they recommended that the university 
abort the conversion underway since 1985 and instead make a speedier and less costly conversion to 
another brand. The president accepted the recommendation and this second conversion was 
completed in nine months. 

Most administrative departments at the university rely on locally designed and written 
software for their mainframe applications. By the time the second conversion was completed in the 
Spring of 1990 and it was possible to begin focusing on system development and major 
programming enhancements, there was a huge backlog of computing needs which had accumulated 
during the development moratorium of the previous four years. This made even more pressing the 
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need to work out an efficient, effective, and equitable procedure for approving projects and setting 
priorities among approved projects. 

Some Pav. Some Don't 

The university has always followed an "economic" model in administrative computing, an 
approach which has come under increasing internal criticism in recent years. Although it never 
attempted to recover costs fully, the university followed a practice of billing the administrative units 
for both programming and running costs. Academic computing at the university, in contrast, has 
been operated totally on a "library" model since the mid-1970s. 

Administrative computer billing has been in terms of "real money" in the sense that in the 
budgets of operating units there was no distinction between funds which could be spent on 
computing and those which could be spent on equipment, travel, etc. Moreover, with a few 
exceptions budgets were not adjusted to accommodate increased computing costs. The economic 
model in administrative computing thus has meant that those administrators and departments with 
the larger budgets had greater access to computing resources, whether or not their computer 
projects were most important from the perspective of university priorities and goals. It also has 
meant that regardless of size of budget, departments often faced unpredictable increases in non- 
discretionary computing rosts without any corresponding increase in their budgets. For example, 
charges for essentially the ;ame level of computing rose from under 50% to almost 70% of the non- 
salary budget of one department over a three-year period. 

Beyond the problems inherent in such an approach, administrative computing at this 
particular university has had an uneven and inequitable cost recovery structure under which several 
major areas were able to play by different rules due to purely historical reasons. While most users 
must pay for all services, one major office is charged for running costs but not for programming, 
and another entire sector is not charged at all. 

As a result of the origin of administrative computing as a branch of the business office in 
the 1960s and its continued control by that sector until the late 1980s, the finance center has never 
been subject to charges either for programming or for running costs. This tradition of free 
computing for the finance area combined with the fact that until recently the computer center 
reported to the financial vice president gave that sector an obvious advantage over other users. 
Even with the growth of computer use in other administrative areas, the financial area still 
represents about half of the usage while accounting for very little of the cost recoveries. The 
unevenness of the "playing field" was particularly evident several years ago when an expensive new 
application software package acquired by the finance center was charged to the computing center's 
budget. It would have been very difficult for any other user area to deflect software acquisition 
costs in a similar way. Although the advantage of reporting lines was eliminated in 1989 with the 
change in reporting structure, the billing structure has not yet been changed due to budget 
adjustments which are needed first and because of emerging plans to eliminate user billing entirely. 

Since the early 1970s when the student record system was first computerized, the registrar s 
office had been assigned a full-time programmer who was budgeted in the computer center. 
Although perhaps originally intended as a temporary and transitional measure, this pattern has 
continued until the present day. Some years ago the arrangement took the form of a programmer 
either physically located in the registrar's office or housed in the computer center but working 
exclusively on registrar systems. For the past decade, however, it has taken the form of the 
computer center keeping track of programming time required by registrar projects and charging 
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this against a credit" of one FTE programmer. As the registrar's ikeeds in recent years have 
generally required less than one FTE programmer, the difference in the credit has at times been 
assigned to projects for admissions, financial aid, and other areas of academic administration. For 
the registrar's office, however, the effect of this historical arrangement has been that it gets is 
programming free but still must pay for all computer running costs. 

Other than the finance center, the registrar's office, and the occasional case of the 
registrar's office programming credit being assigned elsewhere, all other administrative computer 
users must pay for all programming as well as running costs. This has resulted in one of three 
situations as far as those other users are concerned: (a) some users are unable to proceed with 
needed projects because their budgets do not allow the cost, (b) some users manage to get their 
budgets increased to cover the needed expenditures, although there has been no standard 
procedure for such requests, and (c) some users simply find they are overrunning their budgets due 
to unpredictable computing charges and end the year with a deficit. 

Experience With Computer Committees 

As with billing, academic and administrative computing at the university have followed 
quite different paths in the use of committees. For a few years in the 1970s there was a University 
Computer Committee whose membership included both faculty and administrators and which 
nominally had broad jurisdiction over all campus computing. In fact, however, that committee's 
focus and effective jurisdiction were limited to academic uses of the university mainframe 
computer, which at that time was essentially an administrative computer which also allowed a 
certain amount of academic use. 

In the early 1980s, that ineffective universitywide committee was replaced by an Academic 
Computer Committee. The new committee, composed only of faculty and students and focusing 
only on academic computing, has proven to be much more effective than its predecessor. The 
committee has provided an ongoing forum in which to discuss academic computing issues as well as 
a means to facilitate a two-way flow of communication between the providers of computing and the 
users. Moreover, the Academic Computer Committee in the mid-1980s formed the basis for a 
successful planning process for replacement of the academic mainframe (a separate academic 
computer had been acquired in the early 1980s) and has guided the growth in academic computing 
over the last five years. 

In contrast to the situation for the past decade on the academic side, to date there has been 
no effective forum in which administrative computer users could discuss projects and priorities, 
much less have any formal influence upon the general direction of administrative computing at the 
university. This contrast between academic and administrative computing in terms of user 
involvement in decision- making became strikingly obvious in the mid-1980s as planning got 
underway for replacement of both the administrative and academic mainframes. As has been 
discussed in some detail elsewhere (Fennell 1990), the difference in user involvement led to 
significantly different outcomes of the planning processes. 

The outside consultants who were hired to prepare the 1985 hardware conversion plan for 
administrative computing also noted the lack of a structure for involvement of users in 
administrative computing at the university. They pointed out that university computing policies 
usually are developed by a committee made up of management level personnel with a direct interest 
or concern for the effective utilization of computer resources. Concerned about this lack of a sense 
of direction in administrative computing due to the lack of a formal computing policy, the 
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consultants' report urged the university to develop and adopt a formal computing policy addressing 
areas such as organization, scope of services, personnel, planning, setting priorities, budgeting, and 
management. A mechanism for setting priorities was noted as a matter of particular importance. 

The university followed the consultants' 1985 recommendations on hardware and software, 
a decision which lead to a long, costly, and ultimately aborted conversion. No action was taken on 
the consultants* recommendations regarding a long-range plan or establishment of a users 
committee, however. Consequently, influence on computing direction by anyone other than those 
in the direct chain of administrative reporting has continued to be minimal, informal, and sporadic. 



Steps Toward a Better Way 

Following completion of the second administrative mainframe conversion in the Spring of 
1990, the university this Fall is initiating several major changes in administrative computing. One 
change is in reporting structure. After decades of being under the financial vice president and a 
year and a half of reporting to the academic vice president, administrative computing is now being 
placed under the university's newly established executive vice president. This new reporting 
structure should prove to have two distinct advantages. By separating the reporting lines from any 
of the major user areas-either academic or financial--the change places control of administrative 
computing in "neutral territory." Moreover, being more directly under the president's office should 
help strengthen administrative computing in terms of visibility, planning, and funding. 

As soon as administrative computing began reporting to the academic vice president in 
1989, the decision was made to work toward the elimination of computer charges to administrative 
departments once the hardware conversion was completed. As noted above, billing for computer 
use was eliminated more than a decade ago in the area of academic computing, where funding is 
provided centrally and where students and faculty have unlimited free access to computing facilities 
for classroom related work and for research not supported by outside grant funds. Given that the 
system of charging administrative departments for computer work and the corollary expectation 
that the computer center will generate a certain dollar amount of recoveries to help offset its budget 
is merely moving money from one university "pocket" to another, it will be both more efficient more 
equitable to adopt the model which has worked well in the academic area. 

Two factors make the elimination of billing for administrative computing more 
complicated than was the equivalent decision in academic computing, however. Whereas budget 
recoveries from academic use of the computer were quite insignificant at the time the decision was 
made in the 1970s to eliminate such charges, administrative computing recoveries currently account 
for between $400,000 and $500,000 on the "revenue" side of the university's annual budget. To 
adjust for this revenue "loss" which will accompany a move away from billing, the budgets of a 
number of user departments will need to be adjusted downward by the amount they would 
otherwise be paying in computer charges. Determining the appropriate amount for such 
adjustments will be difficult, particularly given the erratic pattern of charges in recent years as result 
of hardware and software conversions. 

The other major difference is that unlike academic computing, the area of administrative 
computing involves significant amounts of system design and applications programming by the staff 
of the computer center. Inefficient, uneven, and inequitable as it may have been, the system of 
charging administrative departments for that work has served to limit the flow of such requests. 
With free access under the anticipated change, procedures must be put in place for evaluating 
proposals and for setting priorities among proposals which are found to have merit and importance. 
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The university intends to address this latter issue through establishment of a two-tier 
committee structure. Although the details of membership have not yet been worked out, the basic 
structure will be that .of a broadly representative administrative users group at the lower level and 
an upper-level planning and policy committee composed of the vice presidents and chaired by the 
executive vice president. The director of information technology will work closely with both groups. 

Under this plan, anyone requesting system design or programming work beyond routine 
maintenance or minor upgrades will be required to present the proposal to the user committee for 
review. The committee will review the proposal carefully, examining its intrinsic merits, the 
importance of the proposal and its urgency relative to other current proposals, and the computer 
staffs estimate of the magnitude of the task. On the basis of its review, the committee will make a 
recommendation as to whether or not the project should be done and-if so— how it fits in terms of 
priority with other pending projects. 

Recommendations from the user committee will then be reviewed by the vice presidents, 
who will make the final decisions regarding project authorization and priority. This is the level at 
which broader questions of computer policy and planning also will be decided, with involvement 
and recommendations from the user committee as appropriate. 

In addition to an appropriate decision-making structure, tb»s approach to resource 
allocation also requires establishment of criteria for judging both tue merits and the priority of 
proposed projects (Bent and Enright 1990). One guiding principle which already has been 
proposed is that priority be given to projects which will bring in more students, bring in more 
money, or save the university money by increased efficiency. Attention also needs to be given to 
projects which serve current students, however, with the goal of increasing student satisfaction with 
the institution which in turn should lead to improved retention (Carroll 1988). 



The university's new approach to approving programming requests and setting priorities 
among competing projects should have several distinct advantages over past practice. For one 
thing, it will provide access for worthy projects regardless of the size of the requesting department's 
budget. Secondly, it will make the process more public and provide a mechanism for review which 
is open to opinion from all major user areas. Finally, of course, there will be a "level playing field" 
in that no individuals or units will have any particular advantage over others as a result of reporting 
lines or historical practices. 
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ABSTRACT 

Early in 1989 The University of Texas System established an office to support efforts to 
share resources for administrative computing. The network to connect the fourteen 
institutions was being completed and some electronic-mail traffic was going through. During 
the summer of 1989 The University of Texas at San Antonio undertook a pilot project to 
move all of our human resources and fiscal support systems to the main administrative 
facility at The University of Texas at Austin. By September 1, 1990 all targeted systems 
were in production. 

The move to consolidate processing is being accomplished at the same time that distributed 
systems are being promoted. This presentation will cover the decision to undertake the 
project, the implications and challenges of this sort of distributed, networked environment, 
the technical questions yet to be resolved and the future plans for adding components and 
applications. 
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Administrative Resource Sharing Between Components of 
The University of Texas: Pilot Project and Future Directions 



ADMINISTRATIVE OVERVIEW: 

The University of Texas at San Antonio is an academic component of The University of 
Texas System which has seven academic and six health units. Founded in 1969, UTSA 
opened for graduate courses in rented quarters in the summer of 1973. In 1975, we moved 
to a 600 acre campus and began admitting our first undergraduates. Now with over 15,000 
students and 2,000 employees - including almost 500 faculty, 40 undergraduate and 22 
graduate degrees are offered. We have one . cooperative doctoral degree with The 
University of Texas at Austin, and are in the approval stage of another Ph. D. Program. We 
have grown rapidly in most areas but many of our administrative areas remain seriously 
understaffed. Understaffed areas include, but are not limited to our Data Processing, 
Accounting, and our Personnel Offices. 

Only recently have we begun an attempt to organize and coordinate the development of our 
administrative systems. Until September 1, 1990, our Payroll, Personnel, Budget, 
Accounting, and Purchasing systems were either non-existent, or were separate systems with 
no integration whatsoever. The Accounting System was, until six months ago, a CICS 
emulation of the original Burroughs posting machine. Our Payroll System was an old CICS 
system recently re-written into Natural under ADABAS. The Personnel Program was the 
best that we had in the fiscal area. It had been written completely in-house, in Natural, and 
we had a computer literate Associate Director of Personnel who used the system as it was 
designed to be used. He wrote many of his own programs, and wrote them very well. 
Unfortunately, he is no longer with us. The budget system existed only in my mind, and in 
Symphony on my PC. In short, we had some fair to good fiscal and human resource 
systems, but no integration, and little on-line capability....and we were operating at a very 
high risk in several areas. 

The Legislature of the State of Texas recently passed legislation mandating uniform Payroll, 
Human Resources, and Accounting Systems. All state agencies, including higher education, 
were faced with being forced into doing something for which we had too short a time frame, 
not enough staff to accomplish the job in the time allotted, and no resources to spend. We 
were also being forced into making our less than satisfactory, non-integrated systems feed 
into the State System without correcting the problems already existing in our own obsolete 
programs. Our Board of Regents was displeased because the data flowing from each 
institution was different and needed a great deal of reconciliation to provide management 
summaries for regental use. They asked our Vice President for Business Affairs, who was 
then our Acting President, if there was any way we could speed up the process, yet not go 
out and re-invent the wheel by buying new packages. Discussions with The University of 
Texas at Austin and UT-System officials indicated that UT-Austin could run UT-San 
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Antonio as a separate component on their IBM 3090, under their already existing fiscal 
systems. It was estimated that at full usage, we would occupy less than one-half of one 
percent of their CPU. We took this to be a window of opportunity-not only for us as a 
user, but for the entire UT System as a means of standardization while saving large amounts 
of the state's resources. 

The advantages to us were quite apparent, and were immediate: 

1. The immediate inclusion into an already existing and proven system. 

2. Since UT- Austin had already been selected as a test site for the required state 
systems, we could buy time and not have to implement these changes into our 
less than perfect existing fiscal and human resource programs. 

3. We needed no extensive, in-house development, that would take our limited 
programming staff away from other duties for projects that would actually be 
"re-inventing wheels." 

4. We had investigated some proprietary programs and found none that would 
provide the unique solutions to Texas higher education problems, without 
large outlays of funds for modifications. 

5. We would provide evidence to the State of Texas that we were serious about 
the savings of state money by our not purchasing or developing yet another 
redundant set of fiscal and human resource systems. 

6. We would indicate to our Regents that we were serious about providing them, 
and the UT-System offices, with consistent information obtained at a much 
lower cost. 

The problems we faced were: 

1. Lack of proper, up-front training. The Personnel and Budget aspects of the 
conversion were really quite simple and required very little effort on our part. 
We had to be sure that the file structure and the data transmitted were 
common to both systems, which was closely monitored by one of our DP 
people and the Director of Personnel. I was closely involved with the Budget 
implementation, and other than a lot of data entry, I had no real problems. 
But, my previous system was PC based, so anything I got was a definite 
improvement. Payroll and Accounting, however, were so complex that the 
staffs in the two offices were overwhelmed. We have made very strong 
suggestions that much more up-front familiarization and training be done 
before implementation begins with other UT-System components who follow 
our lead. 
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2, Lack of coordination of the implementation process. I have suggested that 
each component coming under the System have a designated liaison at UT- 
Austin to handle all of the problems- The UTSA Payroll Officer spent untold 
hours on the telephone, first trying to determine who to talk to, then trying 
to get the problem solved, A liaison would be the contact person who would 
do all of the leg work in getting the problem fixed That liaison, by the way, 
should be someone particularly well versed in the UT-Austin System* One 
other problem of coordination was the lack of understanding by the UT- 
Austin programming staff as to what their change to a program might do to 
someone else. As I stated earlier, this is a massive, very complex, system, and 
such problems may be just a cost of doing business that those of us with less 
sophisticated systems are unaware of, 

3, Lack of responsibility to our unit. The programming staff at UT-Austin has 
done a fantastic job in bringing this all about. However, they are paid by, and 
are responsible to UT-Austin, If we are to successfully carry this concept of 
centralized processing to its expected end, something will have to be done to 
create more of a "service bureau" concept with those members of the DP staff 
involved in the project, UT-San Antonio is only 85 miles from UT-Austin, 
and when we needed personal assistance with problems, we piled into our car 
and drove there. Its less than two hours away. Since UT-E1 Paso is almost 
six hundred miles away, I doubt that they will want to solve their problems in 
that manner since their drive would be more than ten hours. 

Our conversion is still not completed, but it is going to be successful. It will be successful 
because of the efforts of our DP staff, the departments affected, and because the long-term 
benefits of the System far outweigh any short term pain experienced during implementation. 
Our departments will have immediate on-line access to accounting information they recently 
could not get, or had to wait for, I anticipate a great amount of labor savings as we all 
become more familiar with the product. We have already implemented the electronic 
creation of payroll vouchers. On-line appointments of personnel will soon be. implemented 
thus eliminating the need for typing thousands of multi-part appointment forms each year. 

We made a conscious choice to proceed with this conversion even though it meant 
implementation before some of us were ready. Our Acting President last year recognized 
that if we waited for the new President to arrive we could lose a couple of years while the 
question and endless options were being pondered (new presidents tend to ponder 
endlessly,) Now, eleven months after his hiring, and about six months after we began the 
conversion, we are nearing completion. In another six months, I truly believe we will all 
look back and wonder what the problem really was, and we will be proud of what we have 
been able to accomplish in so short a time. 
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TECHNICAL OVERVIEW: 

There are no truly easy conversions, but some are certainly more challenging than others. 
This was one of the best. From a technical perspective, such a cooperative venture had 
been on the horizon for quite some time, and the success of the project was the culmination 
of various preparatory steps. 

UTSA and UT- Austin, along with several other UT components, began the 80's with the 
vision of shared resources. We built similar environments for administrative processing, 
centering on Software AG products, ADABAS, COM-PLETE and NATURAL, the fourth 
generation language. The UT-Austin applications were kept at a level beyond any that 
UTSA could afford, but they shared expertise, techniques, standards, with us generously. 
We also imported some of the software which they had written, such as their on-line job 
submission system. Very little effort was required to make our programmers productive 
when the conversion began and analysis was facilitated by the common understanding of 
data base issues. 

The network to carry the transactions from our campus to the UT-Austin f s mainframe was 
being finished as our project began. The creation of a network for administrative use 
followed the example of the academic network which connects the components with the 
Center for High Performance Computing in Austin, and the work was directed by the same 
System office. UTSA purchased a new communications controller (IBM 3745-170) with 
token ring adapter, anticipating a need for versatility as well as growth, and during the fall 
we were running at 56KB through fiber optic and microwave connections to the Data 
Processing IBM 3090 in Austin. 

The last factor which make the technical work easier was one which ail manuals on project 
management emphasize - we had the unwavering support of upper-level management I was 
allowed to commit about two-thirds of the programming staff for the better part of nine 
months, and we were supported admirably by the Office of Management Information 
Systems of UT-System Administration, as well as by our colleagues at UT-Austin. 

Technically, UTSA gained a great deal from the project: 

1. Purchases which had been planned, but not yet funded, were given higher 
priority. For example, we acquired a mainframe laser printer to be 
compatible with the print being routed from Austin, so that forms (such as 
checks) and reports could be produced locally. 

2. We established upload-download facilities between the two sites, a feature 
which took on greater importance as we began to try for integration between 
the two data bases. 
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3. The network was made available and the transfer rate boosted earlier than 
had been anticipated. Because of our success with the network connection, 
we will soon be a trial site for a remote token ring connection. 

4. UTSA has been able to acquire some products under enhanced system-wide 
contracts. 

5. I was able to divert programming resources from projects, such as HRIS, 
which were scheduled for future implementation. Because. UT-Austin had 
already built the software for that system, we were able to "piggy-back" on 
those reporting modules. Our programming staff was able to devote their 
efforts to the conversion and to building systems which UTSA needed, but we 
hadn't been able to find time for. For instance, we were able to build a 
student loan system which integrates with the financial aid and bursar modules 
of our student records system locally and with the Accounting system in 
Austin. 

There were the usual conversion challenges of data definition, incompatible processing rules 
and formulas. But the technical challenge that was not completely anticipated was: how 
do you integrate two data bases that are physically 80 miles apart for on-line transactions? 
Many of the financial records associated with students should have timely interaction with 
the Accounting system. Half of the data pertinent to faculty are stored in Austin, half in 
San Antonio. We have hopes that in a year or so a product will be introduced which makes 
two ADABAS sites into one conceptual data base. Until then we will be designing and 
writing systems that load data in batch mode to the mainframe where processing will take 
place. We have already experienced some double updates and mistimed loads. 

Ours was the pilot project in a new era of resource sharing, but within weeks of our start 
date, other projects within the UT-System had been approved: 

1. Three of the medical components, using ADABAS and NATURAL, are 
cooperating to build a human resources/payroll system to be located at a 
central medical site. 

2. Three academic components have shown interest in converting to the UT- 
Austin financial systems and UT-E1 Paso has started the preparatory work. 

3. A prototype for a system-wide Executive Information System has been built. 

The smaller components, such as UTSA can look forward to much more complete and 
sophisticated information systems than we could ever have built on our own. 



ERIC 



6 

5.9 



